Re: Tree with leading '0' modes in 1.7.0.3

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Junio C Hamano <gitster@xxxxxxxxx> wrote:
> "Shawn O. Pearce" <spearce@xxxxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]