Re: fast-import deltas

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

 



Mike Hommey <mh@xxxxxxxxxxxx> writes:

> On Tue, Apr 01, 2014 at 10:14:02AM -0700, Junio C Hamano wrote:
> ...
>> Unless you already have your change in the xdelta on hand, or the
>> format your foreign change is in gives sufficient information to
>> produce a corresponding xdelta without looking at the content that
>> your foreign change applies to, it is silly to try to convert your
>> foreign change into xdelta and feed it to fast-import.
>
> The patch format I'm getting from mercurial boils down to:
>   - replace N bytes from offset in the source material with the given
>     M bytes.
> Which can easily be converted to xdelta without looking at the original.

If that is the case, and if you can identify the original in a way
fast-import can understand, it might be interesting [*1*] to add support
for accepting <base object, xdelta> pair in place of blob data, as
Jonathan already hinted earlier.

It would not be sufficient for the receiving fast-import to store
the delta data to its output---it needs to make sure that the base
object is stored in the same output file as well, but that should
not be too complicated.


[Footnote]

*1* I am still not sure how useful the feature would be outside
slurping from Hg and Git---for obvious reasons, though.  As long as
the change is to a cleanly isolated codepath, it would be OK, I
guess.

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