Re: Tree with leading '0' modes in 1.7.0.3

[Nicolas Pitre <nico@fluxnic.net>]

On Fri, 26 Mar 2010, Shawn O. Pearce wrote:

> Nicolas Pitre <nico@fluxnic.net> wrote:
> > On Fri, 26 Mar 2010, Shawn O. Pearce wrote:
> > > Given that GitHub has blessed the world with this corruption,
> > > we may need to modify JGit to accept it.
> > 
> > Should we?
> > 
> > This is going to screw up pack v4 (yes, someday I'll have the time to 
> > make it real).
> 
> Exactly.  I *really* don't want to permit this sort of corruption
> in a Git repository.
> 
> But GitHub's approach here seems to be "Meh, its fine, don't worry
> about it".

It's up to GitHub to fork Git then, and while at it stop calling it Git 
compatible.  Really.  If we start to get slack about the pack format 
like this then every Git reimplementation du jour will make similar 
deviations except in different directions and we'll end up with a mess 
to support.

And in this case there is _no_ excuse as 'git fsck' is actually 
complaining.

My stance has always been that the C Git is authoritative with regards to 
formats and protocols.  It's up to Github to fix their screw-up.

> Its *NOT* fine.  But Avery and Junio might disagree with me.  :-)

FWIW I agree with you.

> Though, FWIW, it might not screw up pack v4.  IIRC from our
> discussions long ago on pack v4, we store "$mode $name" pairs in
> an indexed list, preciously because we needed to support odd modes
> like 10664 from ancient Git binaries.  If we continue to allow this
> corruption, it means we have to ensure $mode is the octal string
> and not the binary value.

Which is a real pity.

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.


Nicolas