On Tue, Sep 17, 2013 at 11:06:07AM -0700, Junio C Hamano wrote: > "Michael S. Tsirkin" <mst@xxxxxxxxxx> writes: > > > On Tue, Sep 17, 2013 at 10:24:19AM -0700, Junio C Hamano wrote: > >> "Michael S. Tsirkin" <mst@xxxxxxxxxx> writes: > >> > >> > So might it not be useful to tweak patch id to > >> > sort the diff, making it a bit more stable? > >> > >> That is one thing that needs to be done, I think. But it would be > >> unfortunate if we have to do that unconditionally, though, as we may > >> be "buffering" many hundred kilobytes of patch text in core. If we > >> can do so without regressing the streaming performance for the most > >> common case of not using the orderfile on the generating side (hence > >> not having to sort on the receiving end), it would be ideal. I am > >> not sure offhand how much code damage we are talking about, though. > > > > So make it conditional on the presence of the orderefile option? > > That would mean that those who set orderfile from configuration in > the future will have to always suffer, I would think. Is that > acceptable? I dunno. > > Also, if the sender used a non-standard order, the recipient does > not know what order the patch was generated, and the recipient does > not use a custom orderfile, what should happen? I thought your idea > was to normalize by using some canonical order that is not affected > by the orderfile to make sure patch-id stays stable, so I would > imagine that such a recipient who does not have orderfile specified > still needs to sort before hashing, no? Thinking about it some more, it's a best effort thing anyway, correct? So how about, instead of doing a hash over the whole input, we hash each chunk and XOR them together? This way it will be stable against chunk reordering, and no need to keep patch in memory. Hmm? -- MST -- 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