From: Johannes Schindelin <johannes.schindelin@xxxxxx> 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@xxxxxx> --- builtin/rebase.c | 4 ++-- 1 file 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; -- gitgitgadget
