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
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=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.
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).