On Tue, Sep 24, 2013 at 02:31:16PM -0700, Jonathan Nieder wrote: > Michael S. Tsirkin wrote: > >>> On Mon, Sep 23, 2013 at 02:37:29PM -0700, Jonathan Nieder wrote: > > >>>> Then start over with sorted hunks (for example > >>>> building a table of offsets within the patch for each hunk to > >>>> support this). > [...] > > Well, then the result is not compatible with what > > original patch-id would produce. > > Nope, I meant sorting to produce what the original patch-id would > produce for a diff with the default sorting order. The result is a > patch-id that can be compared with patch-ids from earlier versions of > git as long as -O<orderfile> was not used (which was already not > compatible with reliable use of patch-id). > > [...] > > Just making sure: is it correct that there's no requirement to use same > > algorithm between patch-ids.c and builtin/patch-id.c ? > > I think so, as long as Documentation/git-cherry.txt is updated to stop > pretending 'git cherry' calls 'git patch-id' and the two get comments > about it, though it seems simpler to keep them roughly the same. > (They already differ in handling of binary files.) How do they differ btw? > Thanks, > Jonathan -- 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