Re: [PATCH] rebase -i: avoid checking out $branch when possible

Thomas Rast [off-list ref] writes:

quoted

 - The user told us not to do the rebase by making insn sheet empty.  In
   other words, this is "aborting the entire rebase", so ideally it
   should come back to the state before the user ran "git rebase"
   command (i.e. where she was before we switched to <branch>).

   I do not think this ideal behaviour is something neither batch or
   interactive rebase has traditionally implemented, but I can see how
   we can sell this as a bugfix to the end users.

That's a convincing argument, so let's make it so.

quoted

 - It turns out that everything is already contained and there is
   nothing to apply, i.e. after this sequence:

	git checkout branch
	git checkout $onto_or_merge_base_between_base_and_branch

   we find out that "git cherry $onto_or_merge_base branch" is empty.

Is there a command missing here?  This alone does not make them the
same, perhaps you meant some resetting.

Actually that was phrased rather poorly.  At least "after this sequence"
should have been "during this sequence inside the implementation of
'rebase -i'".  In other words, the scenario is still where the user
typed:

  git rebase [-i] [--onto $onto] $base $branch

which is defined to be equivalent to

  git checkout $branch && git rebase [-i] [--onto $onto] $base

The first half of the equivalent command succeeds.  We are on $branch.
The second half finds there is nothing to be done.

I think the current code (and probably with your patch) does this in
such a case:

has_action "$todo" ||
	die_abort "Nothing to do"

and the die happens on $branch before we detach (iow, between the two
checkouts), and the user should end up on $branch.  Unlike the case
where the user told us to abort the entire rebase, which we agreed that
we should come back to the original branch above, I think in this case
we should not nullify the first "checkout $branch".