Re: [git-users] Git branch merge strategies

[Igor Djordjevic]

Hi Mark,

On Thursday, July 27, 2017 at 12:48:25 AM UTC+2, Mark Waite wrote:
>
> Yes, your simplification expresses what I was trying to achieve.
>

Good, then we understood each other, thanks for confirming :)
 

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

Understandable. I just moved the "subsequent" (the other way around) merges 
to the end (being fast-forward ones), once the three "incremental" (and 
real) merges are done. Might be easier to comprehend like that, otherwise I 
agree with you`re logic.
 

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

Yes, correct. Even if it`s probably unlikely (or is it?), "no conflict 
octopus merge" scenario is worth mentioning as well, being the 
easiest/simplest one.

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.

Re: [git-users] Git branch merge strategies

[Mark Waite]

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

Re: [git-users] Git branch merge strategies

[Igor Djordjevic]

Hi JNickVA,

On Wednesday, July 26, 2017 at 8:44:13 PM UTC+2, JNickVA wrote:

> 3. and 4. I don't even have enough information to know the state of the 
> master when each of the 2 branches were created
>

What do you mean here? Isn`t Git history showing you the exact state of 
"master" when each of the branches was branched off...?

I guess we are talking about branches inside the same repository, and not 
more unrelated ones? If so, you should be able to get all the info you need 
from Git itself.

Still, depending on how the commits were made (and how informatively their 
messages are written), it will still be a little hassle -- or a lot of pain 
-- to resolve conflicts inside changes made by other people... :( On the 
positive side, merging some ~40 commits of difference shouldn`t be that 
bad... hopefully :)

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

Re: [git-users] Git branch merge strategies

[Igor Djordjevic]

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 

Re: [git-users] Git branch merge strategies

[JNickVA]

Michael,

1. At this stage I am not sure that what is in production is represented by 
the master branch, and if it was at one time, when that might have been.
2. I am taking over the project from a group of developers who have been 
working remotely with little ort no supervision. I have 2 weeks to pick 
their brains. They have made commits without tags of any kind for over 6 
months.
3. and 4. I don't even have enough information to know the state of the 
master when each of the 2 branches were created
5. My goal, as I stated in my post, is to try to resolve the differences 
between the master and branches in an orderly manner.

On Tuesday, July 25, 2017 at 6:47:23 PM UTC-4, Michael Gersten wrote:

>
> On 2017-07-25, at 5:38 AM, JNickVA  
> wrote:
>
> I have recently been put in charge of a code repository that contains a 
> MASTER and several branches. My task is to try to merge the root and the 
> top two most frequently used branches into a new repository. I face two 
> problems: the branches have not been merged to the root in a long time, and 
> the root is the code for a production website. I am looking for a useful 
> strategy for merging the branches into the root, or MASTER, branch.
>
> *Branch One*
> 
> This branch is 7 commits ahead, 35 commits behind master. 
>  
> -  
> *Branch Two* 
>  
> 
> This branch is 760 commits ahead, 7 commits behind master.
>
>  
> One of the branches I wish to merge to the existing root is 7 commits 
> ahead, 35 commits behind master. The other branch is 760 commits ahead, 7 
> commits behind master. What I'm looking for is a strategy for performing 
> the merge. There are no meaningful tags on any of the existing branches.
>
> Thanks
>
>
> So let me see if I understand this correctly:
>
> 1. Master is actual production code that is still in use.
> 2. Both branches are in use by developers that you can talk to and 
> understand what they are doing.
> 3. Branch 1 is a small patch to an older version of master.
> 4. Branch 2 is a big patch to a recent version of master.
> 5. Your goal is to ... what?!?!?
>
> Seriously, what is your goal? You have three different code-bases, with 
> three different programs.
>
>
>
> -- 
> 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+...@googlegroups.com .
> For more options, visit https://groups.google.com/d/optout.
>
>
> ---
> Entertaining minecraft videos
> http://YouTube.com/keybounce
>
>

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