Re: [PATCH] diff: add a config option to control orderfile

["Michael S. Tsirkin" <mst@redhat.com>]

On Tue, Sep 24, 2013 at 12:36:10PM -0700, Jonathan Nieder wrote:
> Michael S. Tsirkin wrote:
> > On Mon, Sep 23, 2013 at 02:37:29PM -0700, Jonathan Nieder wrote:
> 
> >>  a) When asked to compute the patch-id of a seekable file, use the
> >>     current streaming implementation until you notice a filename that
> >>     is out of order.  Then start over with sorted hunks (for example
> >>     building a table of offsets within the patch for each hunk to
> >>     support this).
> >>
> >>     When asked to compute the patch-id of an unseekable file, stream
> >>     to a temporary file under $GIT_DIR to get a seekable file.
> >
> > This can be computed in one pass: just keep two checksums around.
> >
> > But the result won't be stable: if you get same patch from two
> > people one is ordered, the other isn't, you get two different checksums.
> 
> Sorry for the lack of clarity.  In this case (a), I meant "sort the
> diff hunks and use the *old* patch-id definition with sorted hunks,

Well, then the result is not compatible with what
original patch-id would produce.
Basically you are either not stable or not compatible :)

> which produces a stable result but requires random access.
> 
> However:
> 
> [...]
> >>  b) Unconditionally use the new patch-id definition that is stable
> >>     under permutation of hunks.  If and when someone complains that
> >>     this invalidates their old patch-ids, they can work on adding a
> >>     nice interface for getting the old-style patch-ids.  I suspect it
> >>     just wouldn't come up.
> >
> > That's certainly easy to implement.
> 
> Yes, (b) seems like the best option to me, for what it's worth.
> 
> Thanks again,
> Jonathan

OK, thanks.

Just making sure: is it correct that there's no requirement to use same
algorithm between patch-ids.c and builtin/patch-id.c ?