RE: Performance Issues with Git Rebase

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxx]
> Sent: Monday, October 13, 2014 10:26 AM
> To: Crabtree, Andrew
> Cc: git@xxxxxxxxxxxxxxx
> Subject: Re: Performance Issues with Git Rebase
> 
> "Crabtree, Andrew" <andrew.crabtree@xxxxxx> 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).
> 

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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]