RE: Performance Issues with Git Rebase

From: Crabtree, Andrew <andrew.crabtree@hp.com>
Date: Oct 13, 2014, 17:52 UTC
Message-ID: <B82B660D4887C042850326C2BC65FE035D56CD63@G4W3227.americas.hpqcorp.net>
In-Reply-To: <xmqqlhoj51bi.fsf@gitster.dls.corp.google.com>

Ah gotcha.  That makes sense.

Default behavior is to do a patch-id check on all of them which is exactly what you would normally want to happen, and suppressing that speeds things up considerably at the risk of attempting to re-apply an already existing patch.

Thanks much for the explanation.   Perhaps I'll add a progress indicator since my organization will be doing a significant number of these types of rebases in the near future.

Regards, -Andrew

Show 20 quoted lines

> -----Original Message-----
> From: Junio C Hamano [mailto:gitster@pobox.com]
> Sent: Monday, October 13, 2014 10:26 AM
> To: Crabtree, Andrew
> Cc: git@vger.kernel.org
> Subject: Re: Performance Issues with Git Rebase
> 
> "Crabtree, Andrew" <andrew.crabtree@hp.com> writes:
> 
> > I'm getting the same output with both the triple and double dot for my
> > specific case, but I have no idea if that change makes sense for all
> > cases or not.  Any guidance?
> 
> The difference only matters if any of your 4 patches have been sent
> to your upstream and accepted and appear among the 4665 changes they
> have.
> 
> The --cherry-pick option is about cross checking the combinations of
> 4 x 4665 and filter out matching ones (if any).
>