Re: Tree with leading '0' modes in 1.7.0.3

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

 



On Fri, Mar 26, 2010 at 9:56 PM, Nicolas Pitre <nico@xxxxxxxxxxx> wrote:
> On Fri, 26 Mar 2010, Shawn O. Pearce wrote:
>> Its *NOT* fine.  But Avery and Junio might disagree with me.  :-)
>
> FWIW I agree with you.

I would also like to remove my name from the "disagree" list. :)

Producing nonstandard output isn't fine at all - I mentioned Postel's
Law, but the neglected half of that law is that you're supposed to
produce valid data in the first place.  This is why (as I mentioned
earlier) bup's automated tests now run 'git fsck' explicitly to verify
that it gets it right.  It was only the very first versions of bup,
which thankfully nobody used for anything important, that screwed this
up.  Barring any new and improved screw-ups, anyway.

I only brought it up to say that it's actually easy to make this
mistake undetected.  Very few people run git fsck nowadays.  The world
might benefit if git complained (albeit non-fatally) *whenever* it saw
such an incorrect tree.

> In fact, my position is that pack v4 would simply refuse to optimize the
> encoding for such tree objects, period.  Only the non ambiguously
> encoded tree objects would benefit from the v4 improvements.

This sounds very wise to me.

Have fun,

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