Settings and activity

  1. 3 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    1 comment  ·  General  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
    C G commented  · 

    If they're showing up then they are "real" changes (meaning someone saved the file again and checked it in). This means the timestamp changed and there's a new changeset with a metadata change (timestamp, user who committed it, etc). That means in order to fully merge you need to reconcile those differences (by either accepting the new version with unchanged content, or rejecting the new unchanged version in favor of the old unchanged version).

    If your developers/users are committing unchanged files, then that's a process problem and they should stop that. Your diffs and merges would be cleaner.

    In the options for Pending Changes -> "What to find", ensure that your users have "Check the content to determine files as change, not only timestamp" as checked. That should help reduce the number of non-changed files that they check-in. But ultimately it's up to them to not to do this.

    If you don't want any user to be able to check-in a file where the contents haven't changed, you could implement a server-side trigger on "before-checkin" and reject the commit if it contains any files that are unmodified per your requirement. (https://www.plasticscm.com/documentation/triggers/plastic-scm-version-control-triggers-guide#Checkin)

  2. 15 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    3 comments  ·  Git bisync  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
    C G commented  · 

    As a cumbersome workaround, you can clone/sync a git repo to a plastic repo, and ONLY use that plastic repo for bi-directional git syncing, not development. What you can then do is make a second plastic repo and replicate (push/pull) branches as needed between this new repo and your plastic git cyned repo. You can then do development work on your own branches in your second repo and only replicate back the changes you want to your git sync repo, which you can then sync with your actual git repo.

    Yes, it's cumbersome, but it's the only workaround I've found until they implement single branch synchronization with git.

  3. 4 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  General  ·  Flag idea as inappropriate…  ·  Admin →
    C G shared this idea  ·