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
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