Re: Tree with leading '0' modes in 1.7.0.3

["Shawn O. Pearce" <spearce@spearce.org>]

Nicolas Pitre <nico@fluxnic.net> wrote:
> On Fri, 26 Mar 2010, Shawn O. Pearce wrote:
> > "Mike.lifeguard" <mike.lifeguard@gmail.com> wrote:
> > > On 10-03-26 08:56 PM, Avery Pennarun wrote:
> > > > The problem is that everything in git works perfectly with these
> > > > invalid file modes *except* fsck, and there's rarely a need to run
> > > > fsck, so this problem can hide for a long time.
> > > 
> > > So, does the error matter or not? If it doesn't matter, then shouldn't
> > > Jgit stop whining? If it does, then whatever-it-is needs to be fixed.
> > 
> > Its less harmful than other types of corruption.  But its quite
> > wrong from a format perspective. The hash of the tree differs even
> > though there is no semantic difference in the tree content.
> > 
> > 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".

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


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.

-- 
Shawn.