git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
MTMichael S. Tsirkin <mst@redhat.com>
Date
Sep 17, 2013, 20:14 UTC
Message-ID
<20130917201401.GA22000@redhat.com>
In-Reply-To
<xmqq38p3z5kg.fsf@gitster.dls.corp.google.com>
On Tue, Sep 17, 2013 at 11:06:07AM -0700, Junio C Hamano wrote:
Show 29 quoted lines
> "Michael S. Tsirkin" <mst@redhat.com> writes:
> 
> > On Tue, Sep 17, 2013 at 10:24:19AM -0700, Junio C Hamano wrote:
> >> "Michael S. Tsirkin" <mst@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.
> >
> > So make it conditional on the presence of the orderefile option?
> 
> That would mean that those who set orderfile from configuration in
> the future will have to always suffer, I would think.  Is that
> acceptable?  I dunno.
> 
> Also, if the sender used a non-standard order, the recipient does
> not know what order the patch was generated, and the recipient does
> not use a custom orderfile, what should happen?  I thought your idea
> was to normalize by using some canonical order that is not affected
> by the orderfile to make sure patch-id stays stable, so I would
> imagine that such a recipient who does not have orderfile specified
> still needs to sort before hashing, no?

Thinking about it some more, it's a best effort thing anyway, correct?

So how about, instead of doing a hash over the whole input, we hash each chunk and XOR them together?

This way it will be stable against chunk reordering, and no need to keep patch in memory.

Hmm?
-- 
MST
Previous: Michael S. TsirkinNext: Michael S. Tsirkin
Message 12 of 32 in “diff: add a config option to control orderfile”
  1. diff: add a config option to control orderfileMichael S. Tsirkin, Aug 31, 2013
  2. Junio C HamanoSep 3, 2013
  3. Michael S. TsirkinSep 3, 2013
  4. Michael S. TsirkinSep 15, 2013
  5. Michael S. TsirkinSep 15, 2013
  6. Junio C HamanoSep 17, 2013
  7. Michael S. TsirkinSep 17, 2013
  8. Junio C HamanoSep 17, 2013
  9. Michael S. TsirkinSep 17, 2013
  10. Junio C HamanoSep 17, 2013
  11. Michael S. TsirkinSep 17, 2013
  12. Michael S. TsirkinSep 17, 2013
  13. Michael S. TsirkinSep 17, 2013
  14. Jeff KingSep 17, 2013
  15. Michael S. TsirkinSep 17, 2013
  16. Michael S. TsirkinSep 17, 2013
  17. Jeff KingSep 17, 2013
  18. Michael S. TsirkinSep 17, 2013
  19. Jeff KingSep 17, 2013
  20. Junio C HamanoSep 17, 2013
  21. Michael S. TsirkinSep 19, 2013
  22. Michael S. TsirkinSep 23, 2013
  23. Jonathan NiederSep 23, 2013
  24. Jeff KingSep 24, 2013
  25. Michael S. TsirkinSep 24, 2013
  26. Jonathan NiederSep 24, 2013
  27. Michael S. TsirkinSep 24, 2013
  28. Jonathan NiederSep 24, 2013
  29. Michael S. TsirkinSep 24, 2013
  30. Jonathan NiederSep 24, 2013
  31. Michael S. TsirkinSep 17, 2013
  32. Michael S. TsirkinSep 21, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.