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.

- James

Reply via email to