Re: best practices against long git rebase times?

On Mon, Dec 7, 2015 at 11:59 PM, Jeff King wrote: > On Mon, Dec 07, 2015 at 02:56:33PM -0800, Junio C Hamano wrote: > >> Jeff King writes: >> >> > You're computing the patch against the parent for each of those 3000 >> > commits (to get a hash of it to compare

Re: best practices against long git rebase times?

On Sun, Dec 06, 2015 at 05:43:45PM +0100, Andreas Krey wrote: > On Fri, 04 Dec 2015 15:31:03 +, John Keeping wrote: > ... > > I'm pretty sure that you're right and the cherry-pick analysis is where > > the time is spent. > > But I'm pretty surprised as to the amount of CPU time that goes

Re: best practices against long git rebase times?

Jeff King writes: > You're computing the patch against the parent for each of those 3000 > commits (to get a hash of it to compare against the single hash on the > other side). Twelve minutes sounds long, but if you have a really > gigantic tree, it might not be unreasonable. > >

Re: best practices against long git rebase times?

On Mon, Dec 07, 2015 at 02:56:33PM -0800, Junio C Hamano wrote: > Jeff King writes: > > > You're computing the patch against the parent for each of those 3000 > > commits (to get a hash of it to compare against the single hash on the > > other side). Twelve minutes sounds long,

Re: best practices against long git rebase times?

Jeff King writes: > I think you missed John's earlier response which gave several pointers > to such caching schemes. :) Yeah, you're right. > > I used to run with patch-id-caching in my personal fork (I frequently > use "git log --cherry-mark" to see what has made it upstream),

Re: best practices against long git rebase times?

On Fri, 04 Dec 2015 15:31:03 +, John Keeping wrote: ... > I'm pretty sure that you're right and the cherry-pick analysis is where > the time is spent. But I'm pretty surprised as to the amount of CPU time that goes there. I'm now rebasing a single commit with a single blank line added, and

Re: best practices against long git rebase times?

On Fri, 04 Dec 2015 18:09:33 +, demerphq wrote: ... > I bet you have a lot of refs; tags, or branches. We do, but removing them doesn't noticably change the times (12k refs vs. 120, mostly tags). I'm just running the second series, the first (with many refs) ended with rebasing over 3000

Re: best practices against long git rebase times?

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

best practices against long git rebase times?

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

Re: best practices against long git rebase times?

On 4 December 2015 at 18:28, John Keeping wrote: > On Fri, Dec 04, 2015 at 06:09:33PM +0100, demerphq wrote: >> On 4 December 2015 at 16:05, Andreas Krey wrote: >> > Hi all, >> > >> > our workflow is pretty rebase-free for diverse reasons yet. >> > >> > One

Re: best practices against long git rebase times?

On 4 December 2015 at 16:05, Andreas Krey 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

Re: best practices against long git rebase times?

On Fri, Dec 04, 2015 at 06:09:33PM +0100, demerphq wrote: > On 4 December 2015 at 16:05, Andreas Krey 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

Re: best practices against long git rebase times?

On Fri, Dec 4, 2015 at 9:33 AM, demerphq wrote: > In all fairness however, I do believe that some of the recent changes > to git helped, but I dont how much or which. What I do know is we > still have the cron sweeper process cleaning refs. (It broke one of my > repos that I