Yes, your simplification expresses what I was trying to achieve. I specifically merged from master to one so that one could be tested with the merge from master. The subsequent merge from one to master was to have master include a commit which shows one merged into it. Same pattern for master to two, then two to master.
I assumed (possibly incorrectly) that there would be conflicts to resolve in either merging one or two or both to master. I assumed that resolving the conflicts would be easier if there were incremental steps which represented the merges. If there are no conflicts, then isn't the ultimate simplification to merge both 1 and two to master with a single command? $ git checkout master $ git merge one two That will perform an octopus merge and create a merge which has 3 parents, rather than the more common 2 parents. Mark Waite On Wed, Jul 26, 2017 at 4:26 PM Igor Djordjevic <igor.d.djordje...@gmail.com> wrote: > Hi Mark, > > > On Tuesday, July 25, 2017 at 2:58:21 PM UTC+2, Mark Waite wrote: >> >> You might consider a series of steps to perform the merge. Some of the >> steps might include: >> >> 1. Merge from master to branch one so that the diffs between branch >> one and master are only changes on branch one, test the resulting merge. >> Review and understand the remaining differences between master and branch >> one >> 2. Merge from master to branch two so that the diffs between branch >> two and master are only changes on branch two, test the resulting merge. >> Review and understand the remaining differences between master and branch >> two >> 3. Merge from branch one to master, test the resulting merge. This >> resolves branch one into master >> 4. Merge from master to branch two, test the resulting merge >> 5. Merge from branch two to master, test the resulting merge. This >> resolves branch two into master >> >> I`m having some issues following the steps - either I`m missing > something, or they seem unnecessarily complicated...? > > Basically, steps (3) and (5) look like no-operations (fast-forward > merges), once steps (1) and (4) are done. There should be nothing in there > that you can test that you haven`t already tested in steps (1) and (4), > still you propose doing so? > > But then again, for steps (1) and (2) you say to merge from "master" to > branch "one" (or "two"), *"**so that the diffs between branch one and > master are only changes on branch one"* (or two), and that confuses me > the most -- what the diff will show should depends on which side of the > merge you`re looking from, isn`t it? > > So if you merge "master" to "one" and you look from "master": > > $ git checkout one > $ git merge master > # resolve conflicts, test, add, commit merge > $ git diff master one > > ..., indeed, the merge commit will show diff as changes introduced only by > branch "one" - but if you look from perspective of branch "one": > > $ git diff one^ one > > ... diff will show all changes introduced by "master" branch instead > (we`re actually using the second last commit on branch "one" for > comparison, as the last one _is_ the merge commit, thus no difference). > > By default, if we just show the merge commit on branch "one": > > $ git show one > > ... Git produces a "combined" diff, showing changes in comparison to all > merge parents (meaning "master" and "one" in the first case), and it > doesn`t matter which branch you merge into the other, the merge > outcome/result is the same. > > So, unless I`m missing some point, here`re the illustrated steps, for > easier comprehension. Starting situation would look something like this: > > O one > / > ---O---O---O---O---O master > \ > O---O---O---O---O---O---O---O---...---O two > > ... but to make it easier to follow, I`ll simplify it to this: > > O one > / > ---O---O---O master > \ > O two > > > Now, we proceed with the steps you described: > > (*1*) $ git checkout one > $ git merge master > # resolve conflicts, test, add > $ git commit # merge commit M1 > > O-------M1 one > / / > ---O---O---O master > \ > O two > > (*2*) $ git checkout two > $ git merge master > # resolve conflicts, test, add > $ git commit # merge commit M2 > > O-------M1 one > / / > ---O---O---O master > \ \ > O---M2 two > > > So far so good, nothing unusual - but here comes the "no operation" part, > or the "fast-forward" merge in steps (3) and (5) (no work/testing to do): > > (*3*) $ git checkout master > $ git merge one > # fast-forward, no merge commit > > O-------M1 one, master > / / > ---O---O---O > \ \ > O---M2 two > > (*4*) $ git checkout two > $ git merge master > # resolve conflicts, test, add > $ git commit # merge commit M3 > > O-------M1 one, master > / / \ > ---O---O---O \ > \ \ \ > O---M2--M3 two > > (*5*) $ git checkout master > $ git merge two > # fast-forward, no merge commit > > O-------M1 one > / / \ > ---O---O---O \ > \ \ \ > O---M2--M3 two, master > > > Here, I would only add the final step, making all three branches the same, > again being a fast-forward merge (thus no changes, no merge commit): > > (*6*) $ git checkout one > $ git merge master > # fast-forward, no merge commit > > O-------M1 > / / \ > ---O---O---O \ > \ \ \ > O---M2--M3 two, master, one > > > All this laid out, I would agree that this could be a good flow to try, > hoping the diagrams help in following it :) But we could simplify the steps > a bit, focusing on the three important ones. Starting position again: > > O one > / > ---O---O---O master > \ > O two > > ... and first two steps being the same: > > (*1*) $ git checkout one > $ git merge master > # resolve conflicts, test, add > $ git commit # merge commit M1 > > O-------M1 one > / / > ---O---O---O master > \ > O two > > > (*2*) $ git checkout two > $ git merge master > # resolve conflicts, add > $ git commit # merge commit M2 > > O-------M1 one > / / > ---O---O---O master > \ \ > O---M2 two > > > Now, we can skip the previous step (3), being a fast-forward merge, and > directly merge from branch "one" to "two" instead, being basically the same > as step (4) in previous flow (even the branch names differ here): > > (*3*) $ git checkout two > $ git merge one > # resolve conflicts, test, add > $ git commit # merge commit M3 > > O-------M1 one > / / \ > ---O---O---O master > \ \ \ > O---M2--M3 two > > > That concludes the tough part (work/testing to do), now we can just > fast-forward branches "one" and "master" by merging branch "two" into them > (nothing else to do here): > > (*4*) $ git checkout one > $ git merge two > # fast-forward, no merge commit > $ git checkout master > $ git merge two > # fast-forward, no merge commit > > O-------M1 > / / \ > ---O---O---O \ > \ \ \ > O---M2--M3 two, one, master > > > Finally, all three branches are synchronized, pointing to the same > commit/state. > > Did I miss something, or that`s basically what you meant as well? :) > > 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. > -- 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.
