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

From: Stephen Haberman <stephen@exigencecorp.com>
Date: Oct 7, 2008, 02:20 UTC
Message-ID: <20081006212021.04ba9214.stephen@exigencecorp.com>
In-Reply-To: <20081006102118.3e817a0f.stephen@exigencecorp.com>

> I agree with Avi on what the rebase -i -p behavior should be for his
> scenario. This patch makes it so. However, the bane of my existence,
> t3404 is failing ~12 tests in, which is a real PITA to debug, so
> please let me know if this is a worthwhile tangent to continue on.

Ah, good old t3404--it caught me on an aspect I had considered but wanted to avoid--Avi's (and my) preferred "--first-parent" way of listing merges works great if the right hand side of the merge commits are outside of the branch getting rebased.

E.g. my use case is when I merge in a stable release with ~100 commits or so and could potentially want to move it around, perhaps squash around it as Avi pointed it, I don't want all 100 commits that are in the stable branch to be listed in my todo file.

However, t3404 makes a good point that if the right hand of the merge has parents that are going to get rebased, the right hand side does need to be included/shown/rewritten.

I also went and looked at the git-sequencer rewrite of rebase-i and it looks slick. I don't fully understand it yet, but I'm much more inclined now to just let Stephan (& sponors/list) ably handle the problem. Especially since its moving to builtin, it moves the required technical ability to contribute above my current skillset--perhaps that is the intent. :-)

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.

Thanks, Stephen