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