Re: Tree with leading '0' modes in 1.7.0.3

From: Nicolas Pitre <nico@fluxnic.net>
Date: Mar 27, 2010, 01:56 UTC
Message-ID: <alpine.LFD.2.00.1003262142121.694@xanadu.home>
In-Reply-To: <20100327013443.GE10910@spearce.org>

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

Show 15 quoted lines

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

Show 6 quoted lines

> 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