Re: [boost] [timer] conflict between tools/inspect and libs/timer

Subject: Re: [boost] [timer] conflict between tools/inspect and libs/timer
From: Beman Dawes (bdawes_at_[hidden])
Date: 2013-12-28 09:46:56

On Sat, Dec 28, 2013 at 8:50 AM, Peter Dimov <lists_at_[hidden]> wrote:

> Beman Dawes wrote:
>
>> Critical changes on develop dating from February were never merged to
>> trunk, and I set the git merge point I missed them.
>>
>
It turned out the changes were merged into branches/release at the time,
and setting the merge point backed them out! It was probably operator error
on my part. If I had followed the procedure you suggest below, I would have
caught the problem, and done so at a time when it was (1) easy to fix, and
(2) the command history was still available so I could have figured out
what I did wrong.

>
> To avoid such (and other) surprises, what I did was ensure that develop
> and master are identical before doing the first merge.
>
>    git diff --name-status master..develop
>
> gave me an overview on where the two branches differ; the same command
> without --name-status goes into more detail.
>
> (In principle, we all have kept our trunk and release branches in sync, so
> the above ought to have yielded nothing. In practice, however, all
> libraries likely had differences because (1) we sometimes forget to merge,
> (2) sometimes other people changed trunk and didn't merge and we didn't
> know, and (3) Stephen Kelly's Boost-wide changes were only on trunk.)
>
> I then proceeded to identify the commits causing each change. I don't
> remember how exactly I did that, probably by using git log on the modified
> files and by looking at the commit history on Github.
>
> After that, I applied each missing commit using git cherry-pick <sha>.
> That is, if a commit on develop was not present on master, I applied it to
> master with git cherry-pick; and if a commit on master was missing on
> develop (things like that do happen occasionally), I applied it on develop.
> I tried to do this in chronological order, which minimizes conflicts.
>
> What made it more interesting for me is that I sometimes didn't want a
> commit to be part of the initial state, so I reverted it using git revert
> instead of applying it to the other branch using git cherry-pick; but this
> should probably not be needed most of the time.
>
> The final result of all that cherry picking should be a state in which git
> diff master..develop doesn't report any differences. Once there, things are
> a simple "git merge" away.
>
> It's probably too late now for all that explanation, but I already wrote
> it. :-)

I'll add your explanation. I may also move the merge point instructions to
their own page to make them stand out more.

>
>
>  It may take a few days to figure out the best way to fix that.
>>
>
> The first thing I would try is git cherry-pick the missing commits into
> master.
>

I ended up reverting the entire merge point commit, and then compared
master and develop to verify.

(I used TortoiseGit to revert the commit because I wasn't sure how to
revert a commit from the command line leaving subsequent commits in place.)

--Beman