Hi, On Fri, 20 Mar 2020, George Spelvin wrote: > 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
