On Thu, Feb 9, 2017 at 9:16 AM, Igor Djordjevic <igor.d.djordje...@gmail.com > wrote:
> On Thursday, February 9, 2017 at 2:31:33 AM UTC+1, Stephen Morton wrote: >> >> ... (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.) >> > > Please excuse me if the tone of my message felt "snarky" to you, it > certainly wasn`t my intention, and my elaboration was just an honest > attempt to understand what do you want to accomplish, explaining what > confuses me, so that I might try to help _you_, spending _my_ time, lol... > :) I won`t comment your remark any further as it seems (accidentally) > provoked -- not that I appreciate the jumpy attitude, but I`ll take it as > my bad this time, sorry for that once again. > > Otherwise, thank you for your patience, could you please explain this part > (emphasis mine): > > >> ... 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*. >> > > ... and this: > > >> ... 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* >> > > The question here is -- what do you consider a "proper way" of merging > (now, and later), and why? > > I`m asking because, from what I understand about git branch merging, it > takes both heads and a common base for a three-way merge -- which means it > doesn`t really matter if you have (1) a single resolved merge commit or (2) > a conflicting merge commit with iterative resolution commits, the end > result is the same. > > 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). > > Diff between M..E is not the same in both cases, but that doesn`t matter > here -- what does matter is that diffs between the branch heads and the > common base (C..D and C..E) are the same in both cases. > > Now, when you eventually try to merge these two branches, _in both cases_ > you get these two states/snapshots D and E and their common base C as > three-way merge "ingredients", so the merge result is the same in both > cases (as all three parts are the same) -- and that`s why I don`t really > understand why you consider (*1*) proper and (*2*) improper merging, and > what you`re eventually expecting to happen in the subsequent merge(s) > (which should be the same)...? > > Again, please excuse me if I`m missing something here. > > Regards, BugA > > 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. (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.) 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.
