From: Thomas Rast <trast@student.ethz.ch>
To: Lucien Kong <Lucien.Kong@ensimag.imag.fr>
Cc: <git@vger.kernel.org>,
Valentin Duperray <Valentin.Duperray@ensimag.imag.fr>,
Franck Jonas <Franck.Jonas@ensimag.imag.fr>,
Thomas Nguy <Thomas.Nguy@ensimag.imag.fr>,
Huynh Khoi Nguyen Nguyen
<Huynh-Khoi-Nguyen.Nguyen@ensimag.imag.fr>,
"Matthieu Moy" <Matthieu.Moy@grenoble-inp.fr>,
Junio C Hamano <gitster@pobox.com>
Subject: branch --contains is unbearably slow [Re: [PATCHv2] Warnings before rebasing -i published history]
Date: Mon, 11 Jun 2012 13:46:01 +0200 [thread overview]
Message-ID: <87r4tmhy12.fsf_-_@thomas.inf.ethz.ch> (raw)
In-Reply-To: <1339409091-28150-1-git-send-email-Lucien.Kong@ensimag.imag.fr> (Lucien Kong's message of "Mon, 11 Jun 2012 12:04:51 +0200")
[+Cc Junio who wrote branch --contains, and Peff who sped up tag
--contains in ffc4b801.]
Lucien Kong <Lucien.Kong@ensimag.imag.fr> writes:
> "git rebase -i" can be very dangerous if used on an already published
> history. This code detects that one is rewriting a commit that is an
> ancestor of a remote-tracking branch, and warns the user through the
> editor. This feature is controlled by a new config key
> rebase.checkremoterefs.
[...]
> +# Add the name the branches after each pick, fixup or squash commit that
> +# is an ancestor of a remote-tracking branch.
> +add_remoterefs () {
> + while read -r command sha1 message
> + do
> + printf '%s\n' "$command $sha1 $message"
> + git branch -r --contains "$sha1" >"$1.branch"
[...]
> + done >"$1.published" <"$1"
> + cat "$1.published" >"$1"
> + rm -f "$1.published" "$1.branch"
> +}
While I like the idea, I think it unfortunately needs some changes in
'git branch --contains'. That command is unbelievably slow on a
repository with many remote branches, like my git.git:
$ g remote -v | wc -l # note that each appears twice, for fetch/push
28
$ git branch -r | wc -l
364
$ time git branch -r --contains origin/next
origin/next
real 0m32.060s
user 0m31.895s
sys 0m0.036s
I think an upper bound for the runtime of any 'git branch --contains'
should be generating the *complete* topology like this:
$ time git log --graph --oneline --all >/dev/null
real 0m2.637s
user 0m2.246s
sys 0m0.364s
It should also be possible to generate the --contains output for several
commits at the same time. Otherwise the feature will be too painfully
slow for all but the simplest rebases. Currently the startup time for
'rebase -i' to show an editor is near-instantaneous for me; adding N*2s
would be too much on most of my topics, where I tend to gather a handful
of fixups and improvements before the next 'rebase -i' round.
--
Thomas Rast
trast@{inf,student}.ethz.ch
next prev parent reply other threads:[~2012-06-11 11:46 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-07 21:20 [PATCH] Warnings before rebasing -i published history Lucien Kong
2012-06-07 22:04 ` Matthieu Moy
2012-06-08 14:03 ` konglu
2012-06-08 14:25 ` Matthieu Moy
2012-06-08 14:57 ` Junio C Hamano
2012-06-07 22:49 ` Junio C Hamano
2012-06-08 7:32 ` konglu
2012-06-08 8:52 ` Matthieu Moy
2012-06-08 9:18 ` Tomas Carnecky
2012-06-08 9:23 ` Matthieu Moy
2012-06-08 14:55 ` Junio C Hamano
2012-06-11 10:04 ` [PATCHv2] " Lucien Kong
2012-06-11 10:55 ` Matthieu Moy
2012-06-11 11:36 ` konglu
2012-06-11 11:39 ` Matthieu Moy
2012-06-11 11:46 ` Thomas Rast [this message]
2012-06-11 16:16 ` branch --contains is unbearably slow [Re: [PATCHv2] Warnings before rebasing -i published history] Junio C Hamano
2012-06-11 22:04 ` Thomas Rast
2012-06-11 22:08 ` Thomas Rast
2012-06-11 23:04 ` Junio C Hamano
2012-06-11 21:56 ` [PATCHv3 1/2] Warnings before rebasing -i published history Lucien Kong
2012-06-11 21:56 ` [PATCHv3 2/2] Warnings before amending " Lucien Kong
2012-06-12 7:34 ` Matthieu Moy
2012-06-12 15:22 ` Junio C Hamano
2012-06-12 7:45 ` [PATCHv3 1/2] Warnings before rebasing -i " Nguy Thomas
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=87r4tmhy12.fsf_-_@thomas.inf.ethz.ch \
--to=trast@student.ethz.ch \
--cc=Franck.Jonas@ensimag.imag.fr \
--cc=Huynh-Khoi-Nguyen.Nguyen@ensimag.imag.fr \
--cc=Lucien.Kong@ensimag.imag.fr \
--cc=Matthieu.Moy@grenoble-inp.fr \
--cc=Thomas.Nguy@ensimag.imag.fr \
--cc=Valentin.Duperray@ensimag.imag.fr \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.