RE: Performance Issues with Git Rebase

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

-----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" [off-list ref] writes:

quoted

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).