On Thursday, February 9, 2017 at 5:58:56 PM UTC+1, Stephen Morton wrote: > > Thu, Feb 9, 2017 at 11:53 AM, Stephen Morton <[email protected] > <javascript:>> wrote: >> >> On Thu, Feb 9, 2017 at 10:48 AM, Igor Djordjevic <[email protected] >> <javascript:>> 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 <[email protected]> >>>> 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. >>> >> >> *(Oops, hit [send] to early.)* > > *No.* >
Hmm... *Yes*? :D > 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" sections). 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. This is independent of considering each of the individual > commits, to specifically address the point above. What happens if you try > to apply that diff to branchA? Chaos is what happens, on the scale of > hundreds of files, and that's what I'm talking about. > All this has nothing to do with 'git checkout branchA; git merge branchB' you were concerned with and what we were discussing so far. For that merge to happen, only D and E (branch heads) and C (common base) are relevant, that is diffs C..D and C..E, and these are _the same_ in both cases you mentioned. Commits M, X, Y and Z are all irrelevant here (and their diffs as well). If you`re complaining that once you resolve all the merge conflicts in Z and try to merge branchB back to branchA all the hell breaks loose (again), that is very true -- but that is something you`re imposing with your current flow, having branchA and branchB so much different (like totally different projects), and both long living and alive, and still merging between them back and forth. And that is something you still have with your preferred case (1) as well (without commits X, Y and Z), as as soon you try to merge E back to D it`s still the same, _every_ resolution/refactoring contained in merge commit M will get inside your branchA (through that commit E). I had tried to avoid just this kind of wild goose chase with various > disclaimers in my question. Apparently not. I appreciate that in you think > you are trying to help. But you are not. Perhaps after this email you will > finally get your "aha moment" and finally get to the point of understanding > where I was when I first wrote my first post, I do not know. But I am not > going to reply further. > Hmm, that`s pretty ignorant for someone asking for help in a public space, but oh well, you have every right to do so :) *Perhaps after this e-mail you will finally get your "aha moment" and finally get to the point of* _actually showing_ what you want to accomplish in the first place (and what I asked for in my very first e-mail here, still in vain), so someone might actually get a chance to help you...? Might be you`d be better off with git-rebase or even git-cherry-pick, at least in one direction, so you don`t merge back and forth between two branches that are not expected to be the same (even worse, they`re expected to be very different), thus git-merge may not be appropriate tool for the job as merging branches is not what you really want, but merely porting changes between them (once the initial merge is done). -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
