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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Sep 17, 2013 at 11:06:07AM -0700, Junio C Hamano wrote:
> "Michael S. Tsirkin" <mst@xxxxxxxxxx> writes:
> 
> > On Tue, Sep 17, 2013 at 10:24:19AM -0700, Junio C Hamano wrote:
> >> "Michael S. Tsirkin" <mst@xxxxxxxxxx> 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.

Well it's just two passes over a diff. Are we optimizing this
for tape based systems or something?

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

If you like, but I don't really care. It's fine with me to make this
conditional on specifying an order file on recepient side.
Or we can make it a separate option.
Or we can stick some hint about the order in the patch.

Tell me what you prefer :)

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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]