From: Johannes Schindelin <johannes.schinde...@gmx.de>
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 HEAD was an ancestor, `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. So let's avoid that
unnecessary work.
Signed-off-by: Johannes Schindelin <johannes.schinde...@gmx.de>
---
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
