Subject: Re: [boost] [GitHelp] (Mis-)Understanding merge
From: Edward Diener (eldiener_at_[hidden])
Date: 2014-02-26 03:12:35
On 2/26/2014 2:28 AM, Daniel James wrote:
> On 26 February 2014 06:50, Edward Diener <eldiener_at_[hidden]> wrote:
>> I was following Modular Boost document "Establishing a merge point after SVN
>> Conversion" (https://svn.boost.org/trac/boost/wiki/PostCvtMergePoint) and
>> everything appeared to go well. I did my 'merge', 'commit', and 'push'
>> specified at the end of the document and things seemed pretty good so I was
>> confident I had established a correct merge point.
>>
>> Knowing that the latest 'develop' had been pushed and tested I determined to
>> update 'master' with the latest 'develop' prior to pushing it. So I did a
>> merge from 'develop' to 'master' and after carefully fixing a few minor
>> conflicts in favor of the 'develop' versions the merge was successful.
>>
>> Yet when I looked at the files involved I noticed that a file which was in
>> 'develop' was not in 'master'. How can this be ? If I merge from 'develop'
>> to 'master' are not any files in 'develop' which are not in 'master' added
>> automatically to 'master' ? If this is not the case it seems that a 'merge'
>> is not doing what I expect it to do. Am I really expected to have to
>> manually add files to 'master' which are in 'develop' and not in 'master'
>> prior to the merge, or I have I missed some 'merge' functionality that would
>> have done this for me automatically ?
>
> Assuming you're talking about preprocessor
Yes, how did you figure that out ?
> there are a lot of
> differences between master and your merge base, when you merge git
> won't take these into account - it only deals with changes made after
> the last merge.
I thought Git was always smart enough to find the merge base and then do
a three way merge between the merge base, the commit being merged to and
the commit being merged from.
> This is the tricky thing about transitioning from
> subversion to git, they have different models of merging, subversion
> is based on tracking individual changesets, git is based on the
> history graph. You could try finding the old changesets that haven't
> been merged and cherry pick them.
This would theoretically mean that I would have to go one by one through
every 'develop' change. Ugh ! I thought Git was supposed to save me from
having to do all that tedious work.
> In this case, I found the commit by
> doing:
>
> > git log origin/develop --
> include/boost/preprocessor/seq/variadic_seq_to_seq.hpp
>
> commit b60a47252d1b87d169bc4eac2b19f6c2916e9983
> Author: Paul Mensonides <pmenso57_at_[hidden]>
> Date: Wed Sep 26 04:50:27 2012
>
> added VARIADIC_SEQ_TO_SEQ
>
> [SVN r80704]
You are a genius ! That is the one that did not get added when I merged
to 'master' from 'develop'. I still do not understand why Git was not
smart enough to realize that.
>
> This gave me the change that need to be cherry picked:
>
> > git cherry-pick b60a47252d1b87d169bc4eac2b19f6c2916e9983
>
> But even after doing that there are still a lot of old changes that
> need to be merged, mainly in the documentation:
>
> > git diff --stat 5e0422ff9732b0ddb2908f381d58d6241b0d8461
> (master)
> doc/headers.html | 32
> ++++++++++++++++----------------
> doc/headers/facilities.html | 2 +-
> doc/headers/facilities/overload.html | 4 ++--
> doc/headers/tuple.html | 18 +++++++++---------
> doc/headers/tuple/eat.html | 2 +-
> doc/headers/tuple/elem.html | 2 +-
> doc/headers/tuple/enum.html | 4 ++--
> doc/headers/tuple/rem.html | 4 ++--
> doc/headers/tuple/reverse.html | 2 +-
> doc/headers/tuple/size.html | 4 ++--
> doc/headers/tuple/to_array.html | 4 ++--
> doc/headers/tuple/to_list.html | 2 +-
> doc/headers/tuple/to_seq.html | 2 +-
> doc/headers/variadic.html | 14 +++++++-------
> doc/headers/variadic/elem.html | 4 ++--
> doc/headers/variadic/size.html | 4 ++--
> doc/headers/variadic/to_array.html | 4 ++--
> doc/headers/variadic/to_list.html | 4 ++--
> doc/headers/variadic/to_seq.html | 4 ++--
> doc/headers/variadic/to_tuple.html | 4 ++--
> doc/ref.html | 36
> ++++++++++++++++++------------------
> doc/ref/overload.html | 4 ++--
> doc/ref/tuple_eat.html | 8 ++++----
> doc/ref/tuple_elem.html | 6 +++---
> doc/ref/tuple_enum.html | 8 ++++----
> doc/ref/tuple_rem.html | 8 ++++----
> doc/ref/tuple_rem_ctor.html | 8 ++++----
> doc/ref/tuple_reverse.html | 8 ++++----
> doc/ref/tuple_size.html | 4 ++--
> doc/ref/tuple_to_array.html | 8 ++++----
> doc/ref/tuple_to_list.html | 8 ++++----
> doc/ref/tuple_to_seq.html | 8 ++++----
> doc/ref/variadic_elem.html | 4 ++--
> doc/ref/variadic_seq_to_seq.html | 2 +-
> doc/ref/variadic_size.html | 4 ++--
> doc/ref/variadic_to_array.html | 4 ++--
> doc/ref/variadic_to_list.html | 4 ++--
> doc/ref/variadic_to_seq.html | 2 +-
> doc/ref/variadic_to_tuple.html | 4 ++--
> doc/topics/variadic_macros.html | 7 ++++---
> include/boost/preprocessor.hpp | 2 +-
> include/boost/preprocessor/config/config.hpp | 2 +-
> 42 files changed, 135 insertions(+), 134 deletions(-)
>
> You could try to track down all the appropriate changes, but IMO the
> best thing to do is to get develop to a release-worthy point and just
> overwrite master from develop.
I could do that. If I did do I just push 'develop' to 'origin/master' ?
I could also, after having done my local merge, just do a 'git diff
master develop' and then update master with appropriate changes.
I am probably naive but I still do not understand why the 'git merge
develop' from the 'master' branch did not work correctly by adding the
variadic_seq_to_seq.hpp file to 'master' that is in my local 'develop'.
My understanding of merging in Git is obviously still deficient.