Re: [PATCH 0/2] update internal patch-id to use "stable" algorithm

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

 



"Jerry Zhang via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes:

> Internal usage of patch-id in rebase / cherry-pick doesn't persist
> patch-ids, so there's no need to specifically invoke the unstable variant.
>
> This allows the unstable logic to be cleaned up.

While all of that may be true, two things are not explained.  

 * Why does "unstable" need to be "cleaned up"?  Is that too dirty
   in what way?

 * If internal usage does not persist patch-ids generated by the
   machinery, why is it bad to be using the unstable variant?  A
   naïve expectation would be to make sure you use stable one if you
   want a future recomputation to give you the same result, but the
   opposite does not have to be always true.





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

  Powered by Linux