How to manage merges from one line while excluding its merges from another

How to manage merges from one line while excluding its merges from another

[Lane Brooks]

I have a tree like this:

      G---H---I---J---K   devel
     /       /       /
A---B---C---D---E---F    main
         \
          L---M---N---O   my


The 'my' branch forked off the 'main' line and for reasons out of my 
control cannot merge the 'main' changes (D,E,F) back.

The 'devel' line is a another line that I need to track and merge from, 
but I only want the changes local to that branch that are not on from 
the mainline. i.e., I only want commits G,H,J.

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.

Is there an automated way to do this or do I have to cherry pick 
everything by hand?

Thanks,
Lane

Re: How to manage merges from one line while excluding its merges from another

[Jonathan Nieder]

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

Re: How to manage merges from one line while excluding its merges from another

[Lane Brooks]

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

Re: How to manage merges from one line while excluding its merges from another

[Jonathan Nieder]

Lane Brooks wrote:

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

Good point.

  git cherry my devel main |
  grep -v ^- |
  while read mark rev
  do
	git cherry-pick $rev ||
	{
		echo >&2 cherry-pick failed
		break
	}
 done

I hadn’t known about the third argument to ‘git cherry’ before.
Thanks for the example.