Re: Tree with leading '0' modes in 1.7.0.3

From: Shawn O. Pearce <spearce@spearce.org>
Date: Mar 27, 2010, 19:20 UTC
Message-ID: <20100327192018.GG10910@spearce.org>
In-Reply-To: <7vvdci2vk8.fsf@alter.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> wrote:

Show 8 quoted lines

> "Shawn O. Pearce" <spearce@spearce.org> writes:
> 
> > 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.  :-)
> 
> Did I ever say it is _fine_?  I thought I said "complain loudly".

I apologize if I misrepresented you above.

> That would at least give poor jgit users who have hit such a corrupted
> object a chance to get a controlled notice and ask for help (and get an
> insn to recover with filter-branch that appeared in this thread).

Well, there is "complain loudly but do it anyway" and "hard stop".

JGit currently has the leading '0' be a "hard stop". Because this is the fsck code running inside of the receive-pack service, validating what the user sent is isn't malformed. Its clearly malformed.

This only got discovered because Mike tried to take a repository from GitHub and push it into Gerrit Code Review, where JGit's fsck routine cannot be bypassed during receive-pack.

Are you suggesting JGit should change its behavior to be "complain loudly but do it anyway"? I'm open to making the code change there if that is how you think a Git implementation should behave in this case. But I don't want to do it just to match CGit's behavior, sometimes CGit can be wrong. :-)

-- 
Shawn.