"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 can still buy "--stable is not about stability across versions of Git"--it makes our job easier ;-) I just want to make sure that "--stable is about stability inside a single version of Git that patch ID for the same commit will stay the same and unaffected by random end-user configuration knobs". Which in turn would mean that we won't have to worry about this option in patch-id as long as we remove the diff.compactionheuristic configuration and command line option once the developers are done experimenting with their heuristics code. -- 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