On Fri, Sep 6, 2013 at 8:25 PM, Nicolas Pitre <n...@fluxnic.net> wrote:
> On Fri, 6 Sep 2013, Duy Nguyen wrote:
>> On Fri, Sep 6, 2013 at 10:23 AM, Nicolas Pitre <n...@fluxnic.net> wrote:
>> > On Fri, 6 Sep 2013, Nguy­n Thái Ng÷c Duy wrote:
>> >
>> >>
>> >> Signed-off-by: Nguy­n Thái Ng÷c Duy <pclo...@gmail.com>
>> >> ---
>> >>  Should be up to date with Nico's latest implementation and also cover
>> >>  additions to the format that everybody seems to agree on:
>> >>
>> >>   - new types for canonical trees and commits
>> >>   - sha-1 table covering missing objects in thin packs
>> >
>> > Great!  I've merged this into my branch with the following amendment:
>> I'd like to propose another change in the format to basically limit
>> the use of sha1ref format "\0<SHA-1>" to tree entries only. All forms
>> of deltas must have non-zero sha1 index (i.e. reference to SHA-1
>> table). It will simplify handling code, and I think it makes sense too
> Why?
> This is still some artificial limitation and I tend not to like them.
> "Simplifying handling code" is not a good enough reason on its own,
> especially if it reduce flexibility for possible future layout
> optimizations.
> In what way is the code more difficult?

That'll be two ways of linking to another in-pack object. The linked
object must be in the pack anyway, its sha-1 should be present in the
sha-1 table. "\0<sha1>" is a longer encoding for nothing. If the
linked sha1 is not in the pack (similar to the old ref-delta), it
makes the pack depend on another one, which is what we've been
avoding. In your code you reject sha1ref starting with zero too
(sha1_file.c::get_base_delta and packv4-parse.c::decode_entries)
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to