From: John Keeping <john@keeping•me.uk>
To: Andreas Krey <a.krey@gmx•de>
Cc: Git Mailing List <git@vger•kernel.org>
Subject: Re: best practices against long git rebase times?
Date: Fri, 4 Dec 2015 15:31:03 +0000 [thread overview]
Message-ID: <20151204153103.GP18913@serenity.lan> (raw)
In-Reply-To: <20151204150546.GA17210@inner.h.apk.li>
On Fri, Dec 04, 2015 at 04:05:46PM +0100, Andreas Krey wrote:
> our workflow is pretty rebase-free for diverse reasons yet.
>
> One obstacle now appearing is that rebases simply take
> very long - once you might want to do a rebase there are
> several hundred commits on the remote branch, and our tree
> isn't small either.
>
> This produces rebase times in the minute range.
> I suppose this is because rebase tries to see
> if there are new commits in the destination
> branch that are identical to one of the local
> commits, to be able to skip them. (I didn't
> try to verify this hypothesis.)
>
> What can we do to make this faster?
I'm pretty sure that you're right and the cherry-pick analysis is where
the time is spent.
I looked into this a couple of years ago and I have a variety of
(half-finished) experiments that might improve the performance of this:
https://github.com/johnkeeping/git/commits/log-cherry-no-merges
https://github.com/johnkeeping/git/commits/patch-id-limit-paths
https://github.com/johnkeeping/git/commits/revision-cherry-respect-ancestry-path
https://github.com/johnkeeping/git/commits/patch-id-notes-cache
http://comments.gmane.org/gmane.comp.version-control.git/224006
I have no idea if any of these changes will apply to modern Git (or if
some of them are even correct) but I can try to clean them up if there's
interest.
The commit for patch-id-limit-paths includes some numbers that might be
relevant for your case:
Before:
$ time git log --cherry master...jk/submodule-subdirectory-ok >/dev/null
real 0m0.373s
user 0m0.341s
sys 0m0.031s
After:
$ time git log --cherry master...jk/submodule-subdirectory-ok >/dev/null
real 0m0.060s
user 0m0.055s
sys 0m0.005s
next prev parent reply other threads:[~2015-12-04 15:31 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-04 15:05 best practices against long git rebase times? Andreas Krey
2015-12-04 15:31 ` John Keeping [this message]
2015-12-06 16:43 ` Andreas Krey
2015-12-07 21:02 ` Jeff King
2015-12-07 22:56 ` Junio C Hamano
2015-12-07 22:59 ` Jeff King
2015-12-08 0:18 ` Junio C Hamano
2015-12-08 17:45 ` Christian Couder
2015-12-04 17:09 ` demerphq
2015-12-04 17:28 ` John Keeping
2015-12-04 17:33 ` demerphq
2015-12-04 18:10 ` Stefan Beller
2015-12-06 16:40 ` Andreas Krey
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=20151204153103.GP18913@serenity.lan \
--to=john@keeping$(echo .)me.uk \
--cc=a.krey@gmx$(echo .)de \
--cc=git@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox