Git Mailing List Archive on lore.kernel.org
 help / color / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Alban Gruin <alban.gruin@gmail.com>
Cc: "SZEDER Gábor" <szeder.dev@gmail.com>,
	git@vger.kernel.org, "Elijah Newren" <newren@gmail.com>,
	"Ævar Arnfjörð" <avarab@gmail.com>,
	"Eugeniu Rosca" <erosca@de.adit-jv.com>,
	"Junio C Hamano" <gitster@pobox.com>, "Jeff King" <peff@peff.net>,
	"Eugeniu Rosca" <roscaeugeniu@gmail.com>,
	"Phillip Wood" <phillip.wood@dunelm.org.uk>
Subject: Re: [PATCH v3] rebase -i: stop checking out the tip of the branch to rebase
Date: Wed, 5 Feb 2020 15:31:08 +0100 (CET)
Message-ID: <nycvar.QRO.7.76.6.2002051531000.3718@tvgsbejvaqbjf.bet> (raw)
In-Reply-To: <20200124150500.15260-1-alban.gruin@gmail.com>


[-- Attachment #1: Type: text/plain, Size: 8130 bytes --]

Hi Alban,

On Fri, 24 Jan 2020, Alban Gruin wrote:

> One of the first things done when using a sequencer-based
> rebase (ie. `rebase -i', `rebase -r', or `rebase -m') is to make a todo
> list.  This requires knowledge of the commit range to rebase.  To get
> the oid of the last commit of the range, the tip of the branch to rebase
> is checked out with prepare_branch_to_be_rebased(), then the oid of the
> head is read.  After this, the tip of the branch is not even modified.
> The `am' backend, on the other hand, does not check out the branch.
>
> On big repositories, it's a performance penalty: with `rebase -i', the
> user may have to wait before editing the todo list while git is
> extracting the branch silently, and "quiet" rebases will be slower than
> `am'.
>
> Since we already have the oid of the tip of the branch in
> `opts->orig_head', it's useless to switch to this commit.
>
> This removes the call to prepare_branch_to_be_rebased() in
> do_interactive_rebase(), and adds a `orig_head' parameter to
> get_revision_ranges().  prepare_branch_to_be_rebased() is removed as it
> is no longer used.

At this point, I am a bit puzzled as a reader: why can we just drop this?
My immediate reaction was: isn't this required to switch to a new branch
when `switch_to` is non-`NULL`?

So I went digging a little. The `prepare_branch_to_be_rebased()` call was
introduced in 53bbcfbde7c (rebase -i: implement the main part of
interactive rebase as a builtin, 2018-09-27).

And looking at the `git-rebase--interactive` part of that patch, it
becomes relatively obvious that we inherited this behavior from the shell
scripting days.

2c58483a598 (rebase -i: rewrite setup_reflog_action() in C, 2018-08-10)
converted the `setup_reflog_action` function (which oddly enough not only
set up the reflog action, but also switched to a new branch if so
configured). That function was introduced in d48f97aa854 (rebase: reindent
function git_rebase__interactive, 2018-03-23), but that was _still_ not
the commit that introduced that "let's check out the upstream" behavior.

It goes _all_ the way back to 1b1dce4bae7 (Teach rebase an interactive
mode, 2007-06-25). Except that back then, it was only done when a branch
name was provided (`git rebase -i <upstream> <branch-to-switch-to>`). So
it behaved correctly.

The problem was introduced in 71786f54c41 (rebase: factor out reference
parsing, 2011-02-06), as it substituted the `if test ! -z "$1"` with `if
test ! -z "$switch_to"`, relying on the command-line parsing of
`git-rebase.sh`.

But wait! Wait, wait, wait! `switch_to` is still only set in that
incantation where we provide a branch name _in addition to_ an upstream
commit.

Ah, I think I slowly see where this is going. The problem is actually
2ec33cdd19b (rebase--interactive: don't require what's rebased to be a
branch, 2010-03-14) which failed to realize that essentially the entire
`git checkout` was necessary to accommodate the subsequent call a mere 8
lines further down from that `checkout`:

		git symbolic-ref HEAD > "$DOTEST"/head-name 2> /dev/null ||
                        echo "detached HEAD" > "$DOTEST"/head-name

So that 2ec33cdd19b commit could have saved itself a lot of trouble by
realizing what the role of that `git checkout` is, and should have pulled
that `head-name` logic into that conditional instead of _actually_
switching to a new branch.

Now, let's see what the C code does to determine "head-name". Indeed, it
is already handled in the option parsing, in that monster of a function
called `cmd_rebase()`.

And yes, I think that `head_name` should also be mentioned in this commit
message, as something like

	git rebase -i <base> <branch-to-switch-to>

should eventually indeed switch to the specified branch, and this here
patch does _not_ break that promise.

This is my only concern with this patch, though, therefore:

Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Thanks,
Dscho

> This introduces a visible change: as we do not switch on the tip of the
> branch to rebase, no reflog entry is created at the beginning of the
> rebase for it.
>
> Unscientific performance measurements, performed on linux.git, are as
> follow:
>
>   Before this patch:
>
>     $ time git rebase -m --onto v4.18 463fa44eec2fef50~ 463fa44eec2fef50
>
>     real    0m8,940s
>     user    0m6,830s
>     sys     0m2,121s
>
>   After this patch:
>
>     $ time git rebase -m --onto v4.18 463fa44eec2fef50~ 463fa44eec2fef50
>
>     real    0m1,834s
>     user    0m0,916s
>     sys     0m0,206s
>
> Reported-by: SZEDER Gábor <szeder.dev@gmail.com>
> Signed-off-by: Alban Gruin <alban.gruin@gmail.com>
> ---
>
> Added a line in the first paragraph to make it clear that the `am'
> backend is not affected.
>
>  builtin/rebase.c | 18 +++++-------------
>  sequencer.c      | 14 --------------
>  sequencer.h      |  3 ---
>  3 files changed, 5 insertions(+), 30 deletions(-)
>
> diff --git a/builtin/rebase.c b/builtin/rebase.c
> index 8081741f8a..6154ad8fa5 100644
> --- a/builtin/rebase.c
> +++ b/builtin/rebase.c
> @@ -246,21 +246,17 @@ static int edit_todo_file(unsigned flags)
>  }
>
>  static int get_revision_ranges(struct commit *upstream, struct commit *onto,
> -			       const char **head_hash,
> +			       struct object_id *orig_head, const char **head_hash,
>  			       char **revisions, char **shortrevisions)
>  {
>  	struct commit *base_rev = upstream ? upstream : onto;
>  	const char *shorthead;
> -	struct object_id orig_head;
> -
> -	if (get_oid("HEAD", &orig_head))
> -		return error(_("no HEAD?"));
>
> -	*head_hash = find_unique_abbrev(&orig_head, GIT_MAX_HEXSZ);
> +	*head_hash = find_unique_abbrev(orig_head, GIT_MAX_HEXSZ);
>  	*revisions = xstrfmt("%s...%s", oid_to_hex(&base_rev->object.oid),
>  						   *head_hash);
>
> -	shorthead = find_unique_abbrev(&orig_head, DEFAULT_ABBREV);
> +	shorthead = find_unique_abbrev(orig_head, DEFAULT_ABBREV);
>
>  	if (upstream) {
>  		const char *shortrev;
> @@ -314,12 +310,8 @@ static int do_interactive_rebase(struct rebase_options *opts, unsigned flags)
>  	struct replay_opts replay = get_replay_opts(opts);
>  	struct string_list commands = STRING_LIST_INIT_DUP;
>
> -	if (prepare_branch_to_be_rebased(the_repository, &replay,
> -					 opts->switch_to))
> -		return -1;
> -
> -	if (get_revision_ranges(opts->upstream, opts->onto, &head_hash,
> -				&revisions, &shortrevisions))
> +	if (get_revision_ranges(opts->upstream, opts->onto, &opts->orig_head,
> +				&head_hash, &revisions, &shortrevisions))
>  		return -1;
>
>  	if (init_basic_state(&replay,
> diff --git a/sequencer.c b/sequencer.c
> index b9dbf1adb0..4dc245d7ec 100644
> --- a/sequencer.c
> +++ b/sequencer.c
> @@ -3715,20 +3715,6 @@ static int run_git_checkout(struct repository *r, struct replay_opts *opts,
>  	return ret;
>  }
>
> -int prepare_branch_to_be_rebased(struct repository *r, struct replay_opts *opts,
> -				 const char *commit)
> -{
> -	const char *action;
> -
> -	if (commit && *commit) {
> -		action = reflog_message(opts, "start", "checkout %s", commit);
> -		if (run_git_checkout(r, opts, commit, action))
> -			return error(_("could not checkout %s"), commit);
> -	}
> -
> -	return 0;
> -}
> -
>  static int checkout_onto(struct repository *r, struct replay_opts *opts,
>  			 const char *onto_name, const struct object_id *onto,
>  			 const char *orig_head)
> diff --git a/sequencer.h b/sequencer.h
> index 9f9ae291e3..74f1e2673e 100644
> --- a/sequencer.h
> +++ b/sequencer.h
> @@ -190,9 +190,6 @@ void commit_post_rewrite(struct repository *r,
>  			 const struct commit *current_head,
>  			 const struct object_id *new_head);
>
> -int prepare_branch_to_be_rebased(struct repository *r, struct replay_opts *opts,
> -				 const char *commit);
> -
>  #define SUMMARY_INITIAL_COMMIT   (1 << 0)
>  #define SUMMARY_SHOW_AUTHOR_DATE (1 << 1)
>  void print_commit_summary(struct repository *repo,
> --
> 2.24.1
>
>

  parent reply index

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-08 21:43 Unreliable 'git rebase --onto' Eugeniu Rosca
2020-01-08 22:35 ` SZEDER Gábor
2020-01-09  0:55   ` Elijah Newren
2020-01-09 15:03     ` SZEDER Gábor
2020-01-09 17:53       ` Elijah Newren
2020-01-21 19:18       ` [PATCH v1] rebase -i: stop checking out the tip of the branch to rebase Alban Gruin
2020-01-21 20:07         ` Elijah Newren
2020-01-22 20:24         ` Junio C Hamano
2020-01-22 20:47         ` Junio C Hamano
2020-01-24 14:45           ` Alban Gruin
2020-01-24 14:45         ` [PATCH v2] " Alban Gruin
2020-01-24 14:55           ` Alban Gruin
2020-01-24 18:12             ` Junio C Hamano
2020-01-24 15:05           ` [PATCH v3] " Alban Gruin
2020-01-24 18:30             ` Junio C Hamano
2020-02-05 14:31             ` Johannes Schindelin [this message]
2020-01-24 17:11           ` [PATCH v2] " Andrei Rybak
2020-01-09 11:13   ` Unreliable 'git rebase --onto' Eugeniu Rosca
     [not found] ` <CABPp-BHsyMOz+hi7EYoAnAWfzms7FRfwqCoarnu8H+vyDoN6SQ@mail.gmail.com>
2020-01-09 10:53   ` Eugeniu Rosca
2020-01-09 18:05     ` Elijah Newren
2020-01-10  0:06       ` Eugeniu Rosca
2020-01-10  2:35         ` Elijah Newren

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

* 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.2002051531000.3718@tvgsbejvaqbjf.bet \
    --to=johannes.schindelin@gmx.de \
    --cc=alban.gruin@gmail.com \
    --cc=avarab@gmail.com \
    --cc=erosca@de.adit-jv.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=newren@gmail.com \
    --cc=peff@peff.net \
    --cc=phillip.wood@dunelm.org.uk \
    --cc=roscaeugeniu@gmail.com \
    --cc=szeder.dev@gmail.com \
    /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

Git Mailing List Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/git/0 git/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 git git/ https://lore.kernel.org/git \
		git@vger.kernel.org
	public-inbox-index git

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.git


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git