Re: [boost] [git] develop and master are two completely distinct branches

Subject: Re: [boost] [git] develop and master are two completely distinct branches
From: Bjørn Roald (bjorn_at_[hidden])
Date: 2013-12-07 05:27:05

On 12/07/2013 08:38 AM, Ahmed Charles wrote:
>
>
>> Date: Fri, 6 Dec 2013 16:33:35 +0000
>> From: daniel_at_[hidden]
>> To: boost_at_[hidden]
>> Subject: Re: [boost] [git] develop and master are two completely distinct	branches
>>
>> On 6 December 2013 16:20, Thomas Heller <thom.heller_at_[hidden]> wrote:
>>>
>>> I was hoping that the conversion script tracked and conserved this
>>> information. In the current state is close to impossible to see where those
>>> two branches might have diverged. Also, the history of the master branch of
>>> most repositories is close to useless now.
>>
>> The history of branches/release wasn't much better. You can still use
>> subversion to examine the old history, and find out what need to be
>> merged. In this case:
>>
>> svn mergeinfo --show-revs eligible
>> "https://svn.boost.org/svn/boost/trunk/boost/phoenix"
>> "https://svn.boost.org/svn/boost/branches/release/boost/phoenix"
>> r71952
>> r72702
>> r78205
>> r79223
>> r85952
>>
>> svn mergeinfo --show-revs eligible
>> "https://svn.boost.org/svn/boost/trunk/libs/phoenix"
>> "https://svn.boost.org/svn/boost/branches/release/libs/phoenix"
>> r72702
>> r73369
>>
>> Then look through the develop log to find the equivalent git revisions
>> and decide whether they need to be merged.
>>
>> Although I think I'd just create separate clones of master and develop
>> and reconcile the differences manually and then mark it as fully
>> merged. A graphical merge tool could help here.
>
> If you do the following in libs/phoenix:
>
> git checkout develop
> git merge master
> git status # resolve conflicts
> git commit
>
> Then you'll have a point where the history of develop is based on master,
 > which makes future merges easier. Note, at some point you can then
 > merge develop into master, which will publish the changes in phoenix
 > so they will be in the next release. As far as I can tell, the majority
 > of the changes are enabling tests and adding the inline keyword. I'd
> imaginethe goal would be to have master and develop point to the same
> state andgo from there.

In situations like this I often end up using.
gitk --all
view menu --> edit view --> select "Strictly sort by name"
This may be a good friend for boost maintainers as is show develop and 
master graphically side-by-side in chronological order.

gitk let you compare commits simply by selecting one and right-click the 
other and select your option for comparing.

Maybe not so much for phoenix, but for some other libraries with a lot 
of stuff not merged to master (svn release), you may desire to get the 
first merge point in git some place back in history.  If you find your 
most resent commit where the source trees in develop and master are 
equal or are acceptable to merge to master.  Then you can do.

git checkout master
git merge --no-ff <commit-sha1-you-want-to-merge-to-master>
git status # resolve conflicts if any
git commit -am "merged develop->master to get first git merge point"

I use the --no-ff option out of habit, as that is what I most often want 
to do. When merging feature branches into develop or develop into master 
--no-ff ensure that you get a new commit for the merge, and that the 
merge is not simply a fast-forward along the merged-in-branch which 
would include all your intermittent commits in the branch you merge to.

I this case --no-ff does not have any effect as you are very unlikely to 
get a fast forward when merging into master from develop if they are as 
they came out of conversion.

HTH
--
Bjørn