Git Mailing List Archive on
 help / color / Atom feed
From: George Spelvin <lkml@SDF.ORG>
To: Johannes Schindelin <>
Cc: Junio C Hamano <>,,
Subject: Re: Feature request: rebase -i inside of rebase -i
Date: Thu, 26 Mar 2020 00:18:21 +0000
Message-ID: <20200326001821.GB8865@SDF.ORG> (raw)
In-Reply-To: <>

On Wed, Mar 25, 2020 at 08:26:48PM +0100, Johannes Schindelin wrote:
> On Sat, 21 Mar 2020, George Spelvin wrote:
>> My assumption has been that, for simplicity, there would only be one
>> commit in progress, and aborting it aborts everything.
> But that does not necessarily make sense. Imagine that you rebase the
> latest three commits, interactively. Then a merge conflict in the third
> makes you realize that the first commit is no longer needed.
> Enter the nested rebase. You manually re-schedule the failed `pick` via
> `git rebase --edit-todo` and then run the nested rebase: `git reset --hard
> && git rebase -i --nested HEAD~2`.
> Except that you made a typo and said `HEAD~3` instead of `HEAD~2`. You
> delete the entire todo list to get a chance to restart the nested rebase.
> But now the entire rebase gets aborted?

Um, this example is not persuasive.  If I just leave the excess commit at 
the front of the to-do list, then it will be recreated without change.

(Note that if I choose too *small* a nubmer by accident, I can insert a 
"break" at the front of the list and then rebase --nested starting from 

Okay, but what if I screw up worse and type HEAD^55 instead of HEAD^5?
nd that includes multiple merges and other messy stuff?

Well, perhaps a general-purpose optimization could be applied: for the 
first, mandatory, edit-todo, don't actually check out the tree until the 
edit is complete.  When it is, chop off any prefix of unaltered commits 
and start the rebase at the first change.

That would make inadvertently specifying a start point too far back
reasonably harmless.

It would also provide one level of nested abort in the case of a nested 
rebase.  Until you save the initial todo, the rebase doesn't do anything 
except some bookkeeping.  So you could have that be a special case, 
without providing a more general nested --abort.

The main problem with a full nested rebase is that you need to define when 
the inner rebase completes and the outer rebase resumes.  I very much 
want the ability to move commits around between the outer rebase and the 
inner one, which makes that distinction ill-defined.

> If that would happen to me, I would unleash a whole slew of rarely used
> words in the vague direction of whoever implemented the nested rebase
> feature...

The thing is, it's already quite possible to make a mess of a rebase
halfway through and need to abort after you've put a lot of work in.

I think a more general-purpose recovery mechanism might be more

For example, if the --edit-todo included a (commented-out) list of what 
had already been done, then after realizing that you screwed up
conflict resolve b' and have now committed bad resolutions c' and d'
on top of it, you could easily rebase --nested and replace b', c' and d'
with the original b, c and d.

Without aborting and throwing away a' as well, which was perhaps a lot of

>> If I delete any of those five commits, then rebase.missingCommitsCheck
>> will trigger.  If I put y in the list, save it, then change my mind and
>> --edit-todo and delete y, it will also trigger.
> As I said, I am not using that feature myself, so I do not even know what
> "trigger" means in this context. It might totally be okay to use the
> existing code as-is in the context of a nested rebase. That remains to be
> verified, though, I think.

What I mean by "trigger" is thatthe check would notice a missing commit
and produce a warning or error, as configured.

  reply index

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-20 22:30 George Spelvin
2020-03-20 22:51 ` Junio C Hamano
2020-03-20 23:35   ` George Spelvin
2020-03-21 10:51     ` Johannes Schindelin
2020-03-21 17:56       ` George Spelvin
2020-03-25 19:26         ` Johannes Schindelin
2020-03-26  0:18           ` George Spelvin [this message]
2020-03-28 14:25             ` Johannes Schindelin
2020-03-28 16:30               ` George Spelvin
2020-03-31  0:00                 ` George Spelvin
2020-03-31 10:57                   ` Philip Oakley
2020-03-31 13:36                     ` Phillip Wood
2020-04-01 16:43                       ` Philip Oakley
2020-04-07 15:54                         ` Phillip Wood
2020-04-04 12:17                   ` Johannes Schindelin
2020-04-04 12:39                 ` Johannes Schindelin
2020-04-04 17:41                   ` George Spelvin
2020-04-06 10:40                     ` Sebastien Bruckert
2020-04-06 15:24                       ` George Spelvin
2020-04-07  9:16                         ` Sebastien Bruckert
2020-04-07 19:03                           ` George Spelvin
2020-03-30 14:01               ` Philip Oakley
2020-03-30 18:18                 ` George Spelvin
2020-03-30 21:53                   ` Philip Oakley
2020-03-21  8:47 ` Johannes Sixt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200326001821.GB8865@SDF.ORG \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Git Mailing List Archive on

Archives are clonable:
	git clone --mirror git/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 git git/ \
	public-inbox-index git

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone