From: Lane Brooks <lane@brooks.nu>
Date: Sat, 26 Jun 2010 00:35:46 GMT
Subject: Re: How to manage merges from one line while excluding its merges from another
Message-ID: <4C254B62.6020108@brooks.nu>
In-Reply-To: <20100626000358.GA11473@burratino>

On 06/25/2010 06:03 PM, Jonathan Nieder wrote:
> Hi Lane,
>
> Lane Brooks wrote:
>
>    
>> I have a tree like this:
>>
>>       G---H---I---J---K   devel
>>      /       /       /
>> A---B---C---D---E---F    main
>>          \
>>           L---M---N---O   my
>>      
> Nice diagram.
>
> What is missing is a picture of what you want the result to be.
>
>    
>> The 'my' branch forked off the 'main' line and for reasons out of my
>> control cannot merge the 'main' changes (D,E,F) back.
>>      
> [...]
>    
>> I want to continue to merge from the devel line as additional commits
>> are made that are not on the main branch, but I do not want any of
>> the future merge commits.
>>      
> (I) I am guessing that the 'main' line is not part of the published
> history, in which case you what you want might look like this:
>
>           ... devel
>        /
>   A---B---C- ... main
>            \
>             L---M---N---O---H'---J' my
>
> The J commit itself could not be included in the history of the 'my'
> branch because its ancestor D is not meant to be published.
>
> (II) In an alternative scenario, the 'main' changes (D, E, F) are
> forbidden because they introduce bugs.  In this case, a solution might
> look something like this:
>
>         ...                  K devel
>       /               /       \
> A---B---C---D---E---F main    \
>           \                     \
>            L---M---N---O---------P---Q---R---S
>
> where Q, R, and S are commits (created with ‘git revert’) that
> undo the effect of F, E, and D.  From then on, you can just merge
> from devel as usual.
>
>    
>> Is there an automated way to do this or do I have to cherry pick
>> everything by hand?
>>      
> In git 1.7.2, you will be able to automate (I) as follows:
>
>   git cherry-pick --no-merges ^my ^main devel
>
> Until then, you might want to try experimenting with something
> like this:
>
>   git rev-list --no-merges ^my ^main devel |
>   while read rev
>   do
> 	git cherry-pick $rev ||
> 	{
> 		echo>&2 cherry-pick failed
> 		break
> 	}
>   done
>
> Hope that helps,
> Jonathan
>    
I guess (I) is what I want, but your enumerating those two options makes 
me wonder how well things will go when 'devel' and 'main' merge and then 
'my' needs to merge in from 'main'. Seems like a disaster waiting to happen.

I'll take a look at your suggested cherry-pick script. Can it be rerun 
multiple times or is it run one-time only. In others, as 'devel' 
continues to grow can I run it again and will it cherry-pick 
intelligently or will it try to reapply commits already cherry-picked?

Thanks,
Lane