"Michael S. Tsirkin" <m...@redhat.com> writes: > On Wed, Apr 23, 2014 at 10:39:23AM -0700, Junio C Hamano wrote: >> Are these three patches the same as what has been queued on >> mt/patch-id-stable topic and cooking in 'next' for a few weeks? > > Not exactly - at your request I implemented git config > options to control patch id behaviour. > Documentation and tests updated to match.
After comparing the patches 4-6 and the one that has been in 'next' for a few weeks, I tried to like the new one, but I couldn't. The new one, if I am reading the patch correctly, makes the stable variant the default if - the configuration explicitly asks to use it; or - diff.orderfile, which is a new configuration that did not exist, is used. At the first glance, the latter makes it look as if that will not hurt any existing users/repositories, but the thing is, the producer of the patches is different from the consumer of the patches. There needs to be a way for a consumer to say "I need stable variant" on the patches when computing "patch-id" on a patch that arrived. As long as two different producers use two different orders, the consumer of the patches from these two sources is forced to use the stable variant if some sort of cache is kept keyed with the patch-ids. But "diff.orderfile" configuration is all and only about the producer, and does not help the case at all. Compared to it, the previous version forced people who do not have a particular reason to choose between the variants to use the new "stable" variant, which was a lot simpler solution. The reason why I merged the previous one to 'next' was because I wanted to see if the behaviour change is as grave as I thought, or I was just being unnecessary cautious. If there is no third-party script that precomputes something and stores them under these hashes that breaks with this change, I do not see any reason not to make the new "stable" one the default. I however suspect that the ideal "stable" implementation may be different from what you implemented. What if we compute a patch-id on a reordered patch as if the files came in the "usual" order? That would be another way to achieve the stable-ness for sane cases (i.e. no funny "you could split one patch with two hunks into two patches with one hunk each twice mentioning the same path" which is totally an uninteresting use case---diff.orderfile would not even produce such a patch) and a huge difference would be that it would produce the same patch-id as existing versions of Git, if the patch is not reordered. Is that asking for a moon (I admit that I haven't looked at the code involved too deeply)? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
