"Crabtree, Andrew" [off-list ref] 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).
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).