built-in rebase: no need to check out `onto` twice

In the case that the rebase boils down to a fast-forward, the built-in
rebase reset the working tree twice: once to start the rebase at `onto`,
then realizing that the original (pre-rebase) HEAD was an ancestor and
we basically already fast-forwarded to the post-rebase HEAD,
`reset_head()` was called to update the original ref and to point HEAD
back to it.

That second `reset_head()` call does not need to touch the working tree,
though, as it does not change the actual tip commit (and therefore the
working tree should stay unchanged anyway): only the ref needs to be
updated (because the rebase detached the HEAD, and we want to go back to
the branch on which the rebase was started).

But that second `reset_head()` was called without the flag to leave the
working tree alone (the reason: when that call was introduced, that flag
was not yet even thought of). Let's avoid that unnecessary work by
passing that flag.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

1 files changed, 2 insertions, 2 deletions

diff --git a/builtin/rebase.c b/builtin/rebase.c
index 08ec4d52c7..813ec284ca 100644
--- a/builtin/rebase.c
+++ b/builtin/rebase.c
@@ -1740,8 +1740,8 @@ int cmd_rebase(int argc, const char **argv, const char *prefix)
 		strbuf_addf(&msg, "rebase finished: %s onto %s",
 			options.head_name ? options.head_name : "detached HEAD",
 			oid_to_hex(&options.onto->object.oid));
-		reset_head(NULL, "Fast-forwarded", options.head_name, 0,
-			   "HEAD", msg.buf);
+		reset_head(NULL, "Fast-forwarded", options.head_name,
+			   RESET_HEAD_REFS_ONLY, "HEAD", msg.buf);
 		strbuf_release(&msg);
 		ret = !!finish_rebase(&options);
 		goto cleanup;