On Wed, Sep 21, 2022 at 12:16 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > "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. > Fair questions. My broad view is that less code and fewer code paths is better for readability and testing. This isn't a massive impact but it's not theoretical either -- as seen in patch 1 in this series I caught a bug in stable + binary files because of this change. Previously stable patch ids were only used in "git format-patch" and so this corner case was missed, but this becomes less likely if rebase + cherry-pick + format-patch were all on the same scheme.
