Aaron, 20.08.2019, 19:46, "Aaron Miller" <aaronkmil...@gmail.com>: >> Also, just FYI, as far as I know, git-p4 doesn't create "merge" commits, >> so bidirectional integrations won't look different from ordinary commits in >> git commit graph. > > Ah, I didn't realize that, thank you. Perhaps I should just sync each > branch separately then, ignoring branch mappings entirely and be done > with it.
You could do it this way too. But this way your branches will be completely independent. However, with --detect-branches, you'll preserve the information on which branch was branched off at which point. (it's useful for release branches or feature branches; but not really for main and testing branching model) > I was hoping to generate a commit graph that properly represents > integrations as merge commits because our Perforce branches are quite > large. Storing diffs of integrations rather than discrete commits > would result in a much smaller Git repository for us. There are > *quite* a lot of integration commits. Not sure if there'll be a big difference in terms of Git repository size. Git is quite efficient with its delta compression and pack files. > I wonder how hard it would be to modify git-p4 to use merge commits? I > will take a look at the source. It's somewhere around importChanges() and commit(), I suppose. It seems simple on git side (just specify additional parents when creating a commit using "merge" keyword for git fast-import), but may be more complicated on Perforce side (to find the parent(s)). > I'm somewhat surprised that's not the > case to begin with though? Maybe someone else can chime in on why > merge commits aren't used. Yeah, it comes as a bad surprise. One reason I can think of is bi-directional interaction between Perforce and Git -- perhaps some information is lost during submit to P4 and then reimport back to Git. It might also get tricky during import of changelists that span several branches (shouldn't probably be considered a merge though). >> This might not be just because of bidirectional integrations per se. > > I should have mentioned - there were no P4 branch mappings defined for > the depot paths in the test case I shared (maybe that's obvious). Well, you had git-p4.branchList defined, which is enough for --detect-branches logic to kick in. >> One way to filter out troublesome P4 branch mappings is to set >> git-p4.branchUser to a particular user. >> But most likely, this won't help you because different people created >> different branch mappings over time. > > I was thinking I could set git-p4.branchUser to a user that hasn't > created any branches at all and then define branch mappings I care > about in git-p4.branchList. Yeah, it's a good idea. (I did the same) As far as I remember, you can even use a non-existing user for git-p4.branchUser. >> I recreated those merge commits manually (well, in a bash script) using >> `git replace --graft <commit> <parent1> <parent2>` followed by `git >> filter-branch --tag-name-filter cat -- --all` to make grafts permanent. >> >> (`git filter-branch` is only needed once in the very end after all `git >> replace` manipulations are done) >> It's perhaps better to teach git-p4 to produce merge commits, but a bash >> script was a low-tech low-risk option for me. >> >> Also, beware that git-p4 doesn't handle branch-into-non-empty directory >> properly. >> If I remember correctly, something like >> `p4 copy //depot/branchA/... //depot/branchB/... ; p4 submit; p4 copy >> //depot/branchC/... //depot/branchB/...; p4 submit` >> will result in branchB having _both_ branchA and branchC contents in git. >> `git filter-branch` or `git rebase` are your friends to workaround this. >> (or better fix git-p4, of course) Another suggestion: after import into git is done, it might be useful to cross-check tips of git branches against tips of corresponding Perforce branches. (some files may exist in git when they are deleted from Perforce due to the aforementioned branch-into-non-empty directory issue) > These are great tips, thanks! Maybe what I will do is sync each branch > separately with no branch mappings, then use this technique to create > merge commits for the initial branch creation commits only and not > worry about any other integrations. If commits for integrations have consistent commit messages, you might be able to get merge commits using `git replace` cheaper than by modifying git-p4 itself (which can't rely on commit messages). -- Andrey.
