On Wed, Apr 20, 2016 at 09:09:53AM -0700, Junio C Hamano wrote: > "Michael S. Tsirkin" <mst@xxxxxxxxxx> writes: > > > FWIW IIRC what that commit is about is ability to reorder the chunks in > > a patch without changing patch-id. Not about keeping id stable across > > git revisions. > > OK, but "reorder the chunks" is not meant to stay to be the _ONLY_ > purpose for an option whose name is a broad "--[un]stable", but > merely one (and only) possible cause of patch-id instability that > happened to be noticed as an issue back then and was dealt with that > commit, no? In other words, the intent of the "--stable" feature is > to give a stable ID that is not affected by random end-user settings > (e.g. diff.orderfile) and if somebody invents a new configurable knob > in the future, they are supposed to pay attention to the "--stable" > feature or existing users who do use "--stable" will be broken, no? I forgot that we added "--stable". Evne if it is not meant to be about stability across versions, is there any reason _not_ to turn off this heuristic for --stable (or for patch-ids in general)? I guess maybe that creates some inconsistency between generating a patch-id directly, and making one from a diff given on stdin (though I don't know that we can promise much about the latter in the general case; we can fix file ordering, but we don't have enough information to tweak other aspects). -Peff -- 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