On Tue, Sep 17, 2013 at 10:24:19AM -0700, Junio C Hamano wrote: > "Michael S. Tsirkin" <m...@redhat.com> 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. > > > I'll be glad to help do this if you tell me what these parts are. > > anything else besides fixing besides the stand-alone patch id? > > Off the top of my head I do not think of one (but that is not a > guarantee that there isn't any).
Okay so I did this by reworking the internal algorithm used by the stand-alone patch-id (hope you've seen this mail). Now, a question: does it matter whether the algorithm used by diff_get_patch_id is different? Does something rely on them being the same? If yes, we'd have to change diff_get_patch_id as well. -- 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
