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.
