Hi Thomas, On Mon, Jan 31, 2011 at 12:51 PM, Thomas Berg <merlin66b@xxxxxxxxx> wrote: >> Maybe I'm not seeing some obvious limitation, but I can't imagine a >> branching structure that can't be imported into git. Could please you >> give me an example? > > Here I was thinking of the fact that git-p4 (last time I checked the > implementation ) uses the list of branch specs in Perforce for > figuring out the parent of a branch. Our branch specs have changed > over time (they are used for different integration purposes), so they > are no longer usable for this purpose. My personal git-p4 script uses a configuration option to define the list of branches. I also added an option to get the list of branches filtered by user (p4 branches -u), which avoids waiting for the server since I don't have any branches defined. > I also discovered bugs in git-p4: in some cases, if the first submit > to a new branch in Perforce is not identical to the branch it derives > from, the import was not correct. Another thing that I modified was the following lines: 1559 for (prev, cur) in zip(self.previousDepotPaths, depotPaths): 1560 for i in range(0, min(len(cur), len(prev))): 1561 if cur[i] <> prev[i]: 1562 i = i - 1 1563 break This tries to find the root directory of all branches, but does that comparing char by char. So, if you have something like: //depot/branches/branch //depot/branches/branch_test1 //depot/branches/branch_test2 It will assume that your root branch is //depot/branches/branch, which is wrong. I've modified this to split the string by "/" and compare those items, making sure it will detect //depot/branches as the root directory. > One other issue with Perforce, CVS and many other systems is that they > branch per file. Therefore Perforce can represent partial merges > between two branches, which git cannot. Because of this, translating > merges in Perforce to merges in git is not always possible or > desirable: > - if you integrate just one file from one branch to another in > Perforce, and leave the rest unmerged, you probably want to represent > it as a normal git commit (not a merge) > - if you merge almost everything, but leave out a file for some > reason, you may still want to represent it as a merge in git Yes, merge detection is something that is working. I never tried to look into this because I don't find it too important for my work flow. > The git-p4raw tool has excellent handling of merges, see details in > this file around line 4300: > https://github.com/samv/git-p4raw/blob/master/git-p4raw > It supports several algorithms for automatic merge detection, as well > as manually changing it after the import is done. I'll have to look into this later :) Bye, -- Vitor Antunes -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html