Re: best practices against long git rebase times?

From: demerphq <demerphq@gmail.com>
Date: Dec 4, 2015, 17:09 UTC
Message-ID: <CANgJU+Ums-zg1kDiW4mm_X_zxreb=wBVc1gpHUOFN=44x1TyRQ@mail.gmail.com>
In-Reply-To: <20151204150546.GA17210@inner.h.apk.li>

On 4 December 2015 at 16:05, Andreas Krey <a.krey@gmx.de> wrote:

Show 17 quoted lines

> Hi all,
>
> 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 bet you have a lot of refs; tags, or branches.

git rebase performance along with many operations seems to scale proportionately to the number of tags.

At $work we create a tag every time we "roll out" a "server type".

This produces many tags a day.

Over time rebase, and many operations actually, start slowing down to the point of painfulness.

The workaround we ended up using was to set up a cron job and related infra that removed old tags.

Once we got rid of most of our old tags git became nice to use again.

Try making a clone, nuking all the refs in it, and then time rebase and friends.

Yves

-- 
perl -Mre=debug -e "/just|another|perl|hacker/"