On Thursday, February 9, 2017 at 3:47:09 PM UTC+1, Stephen Morton wrote: > > On Thu, Feb 9, 2017 at 9:16 AM, Igor Djordjevic <igor.d.d...@gmail.com > <javascript:>> wrote: > >> For example, single (resolved) merge commit (M): >> >> 1) A---B---C---D branchA >> \ \ >> V---W---*M*---E branchB >> >> ... and conflicting merge commit (M) with multiple merge resolution >> commits (X, Y and Z): >> >> 2) A---B---C---D branchA >> \ \ >> V---W---*M*---*X*---*Y*---*Z*---E branchB >> >> Commits D and E are new commits on the two branches, representing the >> same code state/content in both cases. Commit Z in case (2) has the same >> code state/content as (squash) commit M in case (1). >> >> > I think that after the situation in 2), if you do a `git checkout branchA > ; git merge branchB`, it will try to merge X,Y,Z,E when you only want it to > merge E. You might say "but they'll be no-ops because they're already in > A", but this is just not necessarily true. >
I think you`re wrong here, here`s what the git-merge[1] documentation states (emphasis mine, pay attention to that part): "With the strategies that use 3-way merge (including the default, recursive), if a change is made on both branches, but later reverted on one of the branches, that change will be present in the merged result; some people find this behavior confusing. It occurs because **only the heads and the merge base are considered when performing a merge, not the individual commits**. The merge algorithm therefore considers the reverted change as no change at all, and substitutes the changed version instead." So in both case (1) and (2) above, all that subsequent merge with 'git checkout branchA; git merge branchB' considers/sees are branch head commits D and E, and common base commit C -- only these three, and they`re the same in both cases, thus the merge result is the same, no matter the different individual commits in between. > (This particular case is probably simple to work around, but it's kind of > more general, if you have lots of branches around here, you might not > always be aware of when you need to work around it and it might become much > less easy to work around over time. By making commits to the merge outside > of the merge commit, you've broken git's merge tracking, and suddenly you > can't trust 'git merge' and you don't know if the conflicts you see are > real conflicts or if they're still artifacts from that old crazy merge. > It's just not acceptable.) > I would disagree, as I don`t think there`s anything fancy about git`s "merge tracking", just that given git`s DAG nature/utilization, being able to actually "track merges" is something that falls out of it rather naturally. Thus, I don`t think it`s something you can "break", I`d say "merge tracking" is really just multiple parents pointers resolved during a three-way merge to find the best common ancestor for the next merge... and that is the same in both case (1) and (2) described above. BUT, one may have a misconception in case (2), where you might not know that commits X, Y and Z are in fact "just" resolving conflicts in M, and not a "genuine change" as commit E -- but I`d say that is because you`re doing all the work (both merge resolution and new work) on the same branch... but you already said you`d rather not discuss that :) Anyway, I think the important part here is that even though _you could_ get confused, git won`t. Regards, BugA -- 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.
