Re: Tree with leading '0' modes in 1.7.0.3
- From
Avery Pennarun <apenwarr@gmail.com>
- Date
- Mar 27, 2010, 02:33 UTC
- Message-ID
- <32541b131003261933m940ad70g19b3961d20f5a165@mail.gmail.com>
- In-Reply-To
- <alpine.LFD.2.00.1003262142121.694@xanadu.home>
On Fri, Mar 26, 2010 at 9:56 PM, Nicolas Pitre <nico@fluxnic.net> 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