Re: [PATCH] rebase -i: introduce the 'test' command

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Dec 4, 2018, 09:13 UTC
Message-ID: <nycvar.QRO.7.76.6.1812041007070.41@tvgsbejvaqbjf.bet>
In-Reply-To: <20181203213134.GD8700@sigill.intra.peff.net>

Hi Peff,

On Mon, 3 Dec 2018, Jeff King wrote:

Show 31 quoted lines

> On Mon, Dec 03, 2018 at 08:01:44PM +0100, Johannes Schindelin wrote:
> 
> > > In this sort of situation, I often whish to be able to do nested rebases.
> > > Even more because it happen relatively often that I forget that I'm
> > > working in a rebase and not on the head, and then it's quite natural
> > > to me to type things like 'git rebase -i @^^^' while already rebasing.
> > > But I suppose this has already been discussed.
> > 
> > Varieties of this have been discussed, but no, not nested rebases.
> > 
> > The closest we thought about was re-scheduling the latest <n> commits,
> > which is now harder because of the `--rebase-merges` mode.
> > 
> > But I think it would be doable. Your idea of a "nested" rebase actually
> > opens that door quite nicely. It would not *really* be a nested rebase,
> > and it would still only be possible in interactive mode, but I could
> > totally see
> > 
> > 	git rebase --nested -i HEAD~3
> > 
> > to generate and prepend the following lines to the `git-rebase-todo` file:
> > 
> > 	reset abcdef01 # This is HEAD~3
> > 	pick abcdef02 # This is HEAD~2
> > 	pick abcdef03 # This is HEAD~
> > 	pick abcdef04 # This is HEAD
> > 
> > (assuming that the latest 3 commits were non-merge commits; It would look
> > quite a bit more complicated in other situations.)
> 
> Yeah, I would probably use that if it existed.

I kind of use it, even if it does not exist ;-)

> It would be nicer to have real nested sequencer operations, I think, for
> other situations.

I agree. But for the moment, our data format is too married to the exact layout of .git/, thanks to `git rebase`'s evolution from a Unix shell script.

Alban has this really great patch series to work on the todo list in-memory, and that paves the way to decouple the entire sequencer thing from the file system.

The most notably thing that still would need to be encapsulated would be the options: currently, there is a plethora of inconsistent options files being saved into the state directory (for some, the mere presence indicates `true`, some contain `true` or `false`, others contain text, etc).

> E.g., cherry-picking a sequence of commits while you're in the middle of
> a rebase.

You will be delighted to learn that you can cherry-pick a sequence of commits in the middle of a rebase already. I do `exec git cherry-pick <range>` *all* the time.

Show 5 quoted lines

> But I suspect getting that right would be _loads_ more work, and
> probably would involve some funky UI corner cases to handle the stack of
> operations (so truly aborting a rebase may mean an arbitrary number of
> "rebase --abort" calls to pop the stack). Your suggestion is probably a
> reasonable trick in the meantime.

You know what is an even more reasonable trick? Worktrees.

I only thought about that this morning, but I should have mentioned it right away, as I use it quite frequently.

When I have tricky nested rebases to perform, I do use throw-away worktrees where I check out unnamed branches, work on those, and then integrate them back into the "outer rebase" via the `reset` command in the todo list.

Ciao, Dscho