git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: phillip.wood@dunelm.org.uk
Cc: Johannes Schindelin via GitGitGadget <gitgitgadget@gmail.com>,
	git@vger.kernel.org, Nazri Ramliy <ayiehere@gmail.com>,
	Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH 1/4] built-in rebase: no need to check out `onto` twice
Date: Fri, 1 Mar 2019 14:19:37 +0100 (STD)	[thread overview]
Message-ID: <nycvar.QRO.7.76.6.1903011415220.41@tvgsbejvaqbjf.bet> (raw)
In-Reply-To: <7b1282bf-4b94-5725-00df-2dc63eaa93f0@gmail.com>

Hi Phillip,

On Thu, 28 Feb 2019, Phillip Wood wrote:

> On 28/02/2019 15:27, Johannes Schindelin via GitGitGadget wrote:
> > From: Johannes Schindelin <johannes.schindelin@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.
> 
> 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)

Sorry, I really try to learn how to express things clearly. Still learning
a lot.

So what happens is this: we detect the situation where the pre-rebase
`HEAD` is an ancestor of `onto`. We do this *after* checking out `onto`.
So we now know that we essentially fast-forwarded to the post-rebase
state.

What we still need to do is to update the original ref (unless we were on
a detached HEAD when the rebase was started).

The original shell code updates the original ref to the current HEAD, and
the updates HEAD to point to that symbolic ref instead of being detached.

In the C code, we abused `reset_head()` to do the same. But `reset_head()`
does more: it does a two-way merge (in this instance, because
`RESET_HEAD_HARD` was not part of the flags). Which is unnecessary.

That's all this commit is about.

Ciao,
Dscho

> 
> Best Wishes
> 
> Phillip
> 
> > 
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@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;
> > 
> 

  reply	other threads:[~2019-03-01 13:20 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-28 15:27 [PATCH 0/4] Fix ORIG_HEAD behavior of the built-in rebase Johannes Schindelin via GitGitGadget
2019-02-28 15:27 ` [PATCH 1/4] built-in rebase: no need to check out `onto` twice Johannes Schindelin via GitGitGadget
2019-02-28 20:55   ` Phillip Wood
2019-03-01 13:19     ` Johannes Schindelin [this message]
2019-03-01 15:00       ` Phillip Wood
2019-03-03  1:35         ` Junio C Hamano
2019-03-03 17:09           ` Johannes Schindelin
2019-03-03 19:11           ` Phillip Wood
2019-02-28 15:27 ` [PATCH 2/4] built-in rebase: use the correct reflog when switching branches Johannes Schindelin via GitGitGadget
2019-02-28 15:27 ` [PATCH 3/4] built-in rebase: demonstrate that ORIG_HEAD is not set correctly Johannes Schindelin via GitGitGadget
2019-02-28 15:27 ` [PATCH 4/4] built-in rebase: set ORIG_HEAD just once, before the rebase Johannes Schindelin via GitGitGadget
2019-03-03 17:11 ` [PATCH v2 0/4] Fix ORIG_HEAD behavior of the built-in rebase Johannes Schindelin via GitGitGadget
2019-03-03 17:11   ` [PATCH v2 1/4] built-in rebase: no need to check out `onto` twice Johannes Schindelin via GitGitGadget
2019-03-03 17:11   ` [PATCH v2 3/4] built-in rebase: demonstrate that ORIG_HEAD is not set correctly Johannes Schindelin via GitGitGadget
2019-03-03 17:11   ` [PATCH v2 2/4] built-in rebase: use the correct reflog when switching branches Johannes Schindelin via GitGitGadget
2019-03-03 17:11   ` [PATCH v2 4/4] built-in rebase: set ORIG_HEAD just once, before the rebase Johannes Schindelin via GitGitGadget

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=nycvar.QRO.7.76.6.1903011415220.41@tvgsbejvaqbjf.bet \
    --to=johannes.schindelin@gmx.de \
    --cc=ayiehere@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=gitster@pobox.com \
    --cc=phillip.wood@dunelm.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).