Hi Johannes On 28/02/2019 15:27, Johannes Schindelin via GitGitGadget wrote:
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 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.
I'm confused by this I think I must be missing something. If we've checked out onto then why does the working copy not need updating when we fast forward. (also why to we checkout onto before seeing if we can fast-forward but that's not related to this patch series)
Best Wishes Phillip
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;
