Re: Feature request: rebase -i inside of rebase -i

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Mar 21, 2020, 10:51 UTC
Message-ID: <nycvar.QRO.7.76.6.2003211135380.46@tvgsbejvaqbjf.bet>
In-Reply-To: <20200320233528.GB19579@SDF.ORG>

Hi,

On Fri, 20 Mar 2020, George Spelvin wrote:

Show 14 quoted lines

> On Fri, Mar 20, 2020 at 03:51:20PM -0700, Junio C Hamano wrote:
> > I thought that "git rebase -i" allows the todo file (i.e. list of
> > steps still to be performed) to be edited before continuing; would
> > your use case be supported by using that?
>
> Mostly, if I do it very carefully, which is why I thought it would
> be easy to add.
>
> I think I could manually add the commits to the start of the todo file,
> reset --hard to the old state, and rebase --continue.
>
> But cutting and pasting commit IDs from git log into the todo file,
> and putting fixup commits in the right place is annoyingly fiddly.
> That's exactly the sort of thing computers are good at.

FWIW I have a super-hacky work-around for this use case that I am using in my automation of continuously rebasing Git for Windows' `master` onto the four integration branches of git.git:

1. create a throw-away worktree without checking out the commit

2. fake-run a new `rebase -i` in that worktree, with a custom "editor"
   (which is actually the same script) that simply consumes the todo list,
   aborts the `rebase -i` in the worktree, then deletes the worktree, and
   then inserts that todo list in the original todo list.

3. continue the rebase

I never got around to implement that as a proper "nested" mode of `git rebase -i`, but it should not be too hard. The user interface would probably look somewhat like `git rebase -i --nested <arguments>...` and it would _expect_ an active interactive rebase, and it would insert the todo list into the existing one, at the beginning, with proper commenting, then reset `HEAD` after the user edited the todo list.

My biggest caveat is that I had to force-exit the rebase at some stage due to reasons I only vaguely remember. It had something to do with the replacement cache not being updated when an `exec` is executed that adds a replacement object via `git replace` [*1*]. This issue might have _nothing_ to do with nested rebases, but as I said, my recollection is vague.

There are a couple more concerns, of course, such as: what to do if the user deletes the entire todo list (which is traditionally the only way to abort a rebase)? My gut feeling is that it should go back to the _previous_ version of the todo list.

Another big concern is what to do about `rebase.missingCommitsCheck`: with nested rebases, this will get increasingly tricky. Like, imagine you are rebasing 5 commits, the third of them results in merge conflicts, you realize that it is obsolete and so is now the first, already rebased commit. You do a nested rebase of the latest two commits to drop them, but they don't have their original commit hashes any longer. So it gets a bit finicky to keep track of what commit has been dropped on purpose and what was forgotten to pick instead.

Ciao, Dscho

Footnote *1*: to refresh my recollection, I would have to scour the history of the automation script, see https://github.com/git-for-windows/build-extra/commits/master/ever-green.sh