Bug: git-p4 can generate duplicate commits when syncing changes that span multiple depot paths

Bug: git-p4 can generate duplicate commits when syncing changes that span multiple depot paths

[James Farwell]

Reproduction Steps:

1. Have a git repo cloned from a perforce repo using multiple depot paths (e.g. //depot/foo and //depot/bar).
2. Submit a single change to the perforce repo that makes changes in both //depot/foo and //depot/bar.
3. Run "git p4 sync" to sync the change from #2.


Expected Behavior:

Change should be synced as a single commit to the git repo.


Actual Behavior:

Change is synced as multiple commits, one for each depot path that was affected.


Best Guess:

I believe this is happening because the command syntax "p4 changes //depot/foo/...@123,456 //depot/bar/...@123,456", which git-p4 uses to get the list of changes to sync, will return the same change number multiple times if the change was present in multiple depot paths. This is expected behavior as per the p4 changes documentation: "If p4 changes is called with multiple file arguments, the sets of changelists that affect each argument are evaluated individually. The final output is neither combined nor sorted; the effect is the same as calling p4 changes multiple times, once for each file argument." git-p4 is handling the sorting itself, but it is not handling the combining.

I would imagine this is fixable in the p4ChangesForPaths() method by dropping non-unique elements of the list before or after sorting. Rudimentary testing in the python interpreter would suggest that something like "changes = sorted(set(changes))" should do the trick, but I am no python expert so there may be a better way.


Thanks!
- James