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

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

Hi,

On Wed, 31 Oct 2007, Björn Steinbrink wrote:

quoted

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