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>

Johannes Schindelin committed Mar 3, 2019 at 09:11 UTC e6aac8177d02691bebedec56376ed17239793f9f
1 file changed +2 -2
builtin/rebase.c
+2 -2
@@ -1740,8 +1740,8 @@ int cmd_rebase(int argc, const char **argv, const char *prefix)
1740 strbuf_addf(&msg, "rebase finished: %s onto %s",
1741 options.head_name ? options.head_name : "detached HEAD",
1742 oid_to_hex(&options.onto->object.oid));
1743 - reset_head(NULL, "Fast-forwarded", options.head_name, 0,
1744 - "HEAD", msg.buf);
1743 + reset_head(NULL, "Fast-forwarded", options.head_name,
1744 + RESET_HEAD_REFS_ONLY, "HEAD", msg.buf);
1745 strbuf_release(&msg);
1746 ret = !!finish_rebase(&options);
1747 goto cleanup;