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
--
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.
