Re: [PATCH 1/1] Add --first-parent support to interactive rebase.

From: Björn Steinbrink <b.steinbrink@gmx.de>
Date: Oct 31, 2007, 04:17 UTC
Message-ID: <20071031041751.GA3326@atjola.homenet>
In-Reply-To: <Pine.LNX.4.64.0710310329520.4362@racer.site>

On 2007.10.31 03:34:47 +0000, Johannes Schindelin wrote:

Show 25 quoted lines

> Hi,
> 
> On Wed, 31 Oct 2007, Björn Steinbrink wrote:
> 
> > @@ -246,6 +292,13 @@ OPTIONS
> >  	Instead of ignoring merges, try to recreate them.  This option
> >  	only works in interactive mode.
> >  
> > +\--first-parent::
> > +	Only follow the first parent commits in merge commits when looking
> > +	for the commits that are to be rebased. This is most useful with -p
> > +	as it will cause rebase to recreate the merges against the original
> > +	branches instead of rebasing those branches as well. This option
> > +	only works in interactive mode.
> > +
> 
> Hmm.  I had to read this several times to understand it.  Maybe something 
> like this instead?
> 
> \--first-parent::
> 	When you want to preserve merges, this option allows you to rebase 
> 	only the commits which were not merged in, i.e. which are in the
> 	first parent ancestry of the current HEAD.
> +
> This option only makes sense together with --preserve-merges.

Hm, I think that it might make might sense without -p. Say that your topic branch is following two other branches like this:

---o---o---o--------o topicB
            \        \
--o---A---o---o---o---o---B topicA
         /       /
o---o---o---o---o master

topicB branched off from master earlier than topicA and you currently require stuff from master..topicB _and_ topicB..master, so AFAICT, you need sth. like the above.

Let's say that topicB simplifies some internal API and you desperately wanted to use that, while master introduced some new stuff that you also use. Now your stuff is finished, but it becomes obvious that topicB is still too broken to go into master any time soon. Then you could do:

git rebase -i --first-parent master topicA

to get:

--o---o---o topicB (branched from master somewhere to the left)

             o---o---o---A---B topicA
            /
---o---o---o master

Depending on how much topicA really depends on topicB, you might need to fix a bunch of stuff, but it might be worth it.

How about:
\--first-parent::
	When this option is given and --preserve-merges is not, then
	merge commits are completely ignored and only commits from the
	first parent ancestry are rebased. This allows to pretend that
	merges never happened.

	If --preserve-merges is also given, the merge commits are
	preserved, but only their first parent is rebased as opposed to
	the default behaviour which would rebase all parents.

> Also, could you please add a test case to make sure that your patch works 
> as advertised (and that this functionality will not be broken in future 
> commits)?

Ok, might take some time, as I currently have no clue how the test stuff for git works :-/ Well, I'm sure #git will be helpful :-)

Thanks, Björn