On Tuesday, 7 February 2017 18:25:32 UTC-5, Igor Djordjevic wrote: > > On Wednesday, January 25, 2017 at 11:17:11 PM UTC+1, Stephen Morton wrote: >> >> I'm looking for a git branching and merge strategy for merge with lots of >> conflicts requiring multiple people. I can make it work, and I understand >> git, but it all seems kind of awkward and it feels like there must be a >> better way. >> >> I've got a big git merge to do. There are lots of conflicts and it >> requires many people to resolve them all. >> >> The only way to handle this in git, AFAIK, is to start the merge and then >> just commit all files with conflicts in them and then let different people >> work on the different conflicts, committing them as they go. That is great >> for resolving the conflicts. In the diagram below, branchA is merged into >> branchB with merge commit M. The code in the repo at M is full of >> conflicts. Many of the conflicts in the merge are actually resolved in >> commits x, y, z. >> >> o---o---o---o---- branchA >> \ \ >> \-o---o-M---x---y---z branchB >> >> >> But I worry that the above strategy is not good for git's merge tracking >> and future merges. Because if we do a 'git checkout branchA; git merge >> branchB`, git will erroneously try to merge x,y,z into branchA. >> >> I *could *create branchB2 where I re-do the original merge but then just >> `git checkout z -- . ` and commit that as the merge commit. That would >> work well for the git merge tracking. Then I would keep branchB just as >> historical reference for "who fixed what conflict and why" during the merge. >> >> >> The above would all work, but it seems so un-git-like. It feels like >> there must be a much better and established practice, yet I have not found >> anything online. Is there a better way to do this? >> >> Thanks, >> Steve >> >> p.s. I'm aware of answers like "Your workflow is broken, with git you >> merge often and therefore never have lots of conflicts." It's just too long >> a discussion to argue that point, so let's just avoid it, ok. >> > > I`m sorry, but what I`m missing here is what you are actually trying to > accomplish...? > > I mean, you provided the graph, and you say you`re worried that if you do > 'git > checkout branchA; git merge branchB', commits x, y and z would > "erroneously" end up in branchA, which should mean it is something you > don`t want to happen. > > BUT, then you say that you _could_ redo the merge, do 'git checkout z -- > .' and commit that as resolved merge commit, and you would be happy with > it (once you later merge branchB into branchA to introduce some new changes > from branchB into branch A), keeping old (and unmerged) branchB for > reference (commits x, y, z). > > Now, I`m still pretty new to git, so please excuse me if I`m missing > something, but how would that be different than just simply doing 'git > checkout branchA; git merge branchB' in the first place (with the graph > you`ve shown) - which you said you want to avoid...? > > It seems the only difference would be keeping all x, y, z commits still in > there (branchA history), which you first said you don`t want, but then > later showed that you do actually seem to care about (in terms of changes > they introduce), as you would be fine with committing them all at once as > part of the (resolved) merge commit...? > > I`m sorry if I`m failing to grasp something obvious here, I`m just a bit > confused - you don`t want the commits (initial 'git merge branchB' concern), > but you do want the changes (redo merge, checkout z, resolve commit)... but > you also would like to have the history. But, (1) commits x, y and z _are_ > history, and (2) either way, you end up with with branchA state being the > same (whichever of the two paths you take). > > So, what is that you would actually like to do (and I`m missing to get > here)...? :) > > Regards, > BugA >
Since you freely admit "I'm still pretty new to git", I'll try to explain once. But if I don't quite get it so that you understand, I'm afraid that's all I can do. (My time is better spent perhaps helping answer other people's questions on stackoverflow than helping somebody who, in a somewhat snarky tone, asks me to explain my own question back to them.) - Git is great at merge tracking. Because its DAG implicitly tracks merges. But merge commits are just one single commit. - What if you have a merge whose conflicts are so complex that you cannot resolve them all at once, you have to get a bunch of people to resolve the conflicts slowly over time? I propose a method of accomplishing the conflict resolution (that I take as a premise to my question), but it involves an initial merge commit and then several subsequent commits which cannot be left as the final state because subsequent merges would not happen properly. I am not sure about the best way to take that final repository state and represent in a final series of git merge and commits that make git most happy. - I could just squash all of the commits that were eventually used to resolve all the conflicts into one single merge commit; that would reduce it to a normal git merge. But what if it turned out that a bug was introduced somewhere in there --it is almost inevitable, in fact-- it would probably be useful to have the original conflict resolution commits to see what happened. - So, the question is: what is the best git-like way to a) record the merge in a proper way that will allow any subsequent merges to occur properly (most important) and additionally b) record the intermediate conflict fixing if possible. Steve -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
