git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
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

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