On 4 December 2015 at 16:05, Andreas Krey <a.krey@xxxxxx> wrote: > 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/" -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html