Re: [PATCH RFC] rebase--interactive: if preserving merges, use first-parent to limit what is shown.

[Stephen Haberman <stephen@exigencecorp.com>]

> So, unless I think of something else, I'm done hacking on this and am
> withdrawing the patch.
>
> Though I am curious--with the sequencer, is the Avi/my request of not
> listing out-of-band commits in the todo file going to be handled?
> 
> Some sort of "--first-parent-unless-included-in-rebase" flag.

Okay, I lied--I have a patch that implements this behavior, passes Avi's
script-turned-test, and passes t3404. It implements the above algorithm
of, if in preserving merges mode, start with only first parents in the
todo list, and then recursively prepend right hand side commits to the
todo list only if their parents are going to be rewritten. This drops a
lot of cruft from rebase-i-p with large merges and is very cool, IMHO.

However, lest I burn my "PATCH v2" opportunity, I'm holding off on
posting the updated patch. It works and passes tests but I'm sure I'll
tinker with it some more over the next few days. It will also likely
conflict with my pu sh/maint-rebase3 patch, so I don't know whether to
base it on top of that one or not (guessing not).

Also, I think the patch itself is less interesting than the discussion
of whether this "first parent only" behavior is desired or not.

Obviously I think so--do others agree/disagree?

I've read more into the sequencer, and from what I can tell it still
just drives off a todo of pick/etc. input, and does not generate the
todo itself. So I think my patch is still fair game in terms of how to
generate either the current or the next generation rebase-i-p todo list.

I could be wrong on that though.

Thanks,
Stephen