On Thu, Feb 9, 2017 at 10:48 AM, Igor Djordjevic < igor.d.djordje...@gmail.com> wrote:
> 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> >> 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. > *No.* Think about what the files in the repo looks like at state M and what commits X,Y,Z look like. M has lots of *committed conflict markers in it*. Commit X will 100% definitely involve removing committed conflict markers (and probably removing one of the "ours" or "theirs"). Commit X might also involve code refactoring. So `git diff M E` that you are applying to A will also 100% definitely involve removing a bunch of conflict markers -- 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.
