Jeff King <peff@xxxxxxxx> writes: > I mean that if you save any old patch-ids from "git patch-id", they > won't match up when compared with new versions of git. We can probably > ignore it, though. This isn't the first time that patch-ids might have > changed, and I think the advice is already that one should not count on > them to be stable in the long term. Another thing that this *will* break is the patch signature upload protocol k.org uses to allow Linus, Greg, et al. on the road with limited hotel wifi bandwidth to prepare patch-X-test1.gz and patch-X-test1.sign file. They can locally tag X-test1, prepare "git diff X X-test1 | gzip -n >patch-X-test1.gz" and sign the result, and upload _only_ the detached signature after pushing. They can tell k.org, when uploading the detached signature, to recreate the patchfile by running the same "git diff" to save the bandwidth of sending the same thing twice (as they have to "push" anyway, having to send the generated patch is a pure overhead). Having said all that, kup(1) users are already warned that the textual diff produced by "git diff-tree -p" (which is mentioned in the documentation of the tool) varies across versions of Git and the above "optimization" would not work unless both ends have the same version of Git, so it may not be too big an issue for them. They have already been burned once when we corrected "git archive" output in the past (they obviously have the same optimization to sign tarballs, and the kup(1) mechanism relies to have byte-for-byte identical output). -- 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