Re: Tree with leading '0' modes in 1.7.0.3
- From
A Large Angry SCM <gitzilla@gmail.com>
- Date
- Mar 27, 2010, 19:39 UTC
- Message-ID
- <4BAE5EEC.5090804@gmail.com>
- In-Reply-To
- <20100327193222.GI10910@spearce.org>
Shawn O. Pearce wrote:
Show 22 quoted lines
> A Large Angry SCM <gitzilla@gmail.com> wrote: >> Shawn O. Pearce wrote: >>> IMHO, this leading '0' thing is a similar breakage. We shouldn't >>> relax CGit or JGit to accept it just because the Ruby implementation >>> of Git got the tree encoding wrong. If anything, we should teach >>> these implementations to catch these sorts of problems earlier. >> Just add an additional data point, it looks like up to 16 of these trees >> with zero-padded file modes are reachable from Linus' kernel master ref. > > Frell. > > We can't ask Linus to rewrite his history to repair this breakage. > The fact that its made it into the kernel history means we have > to accept this. The kernel project is simply too large and move > too fast for us to ask them to fix their repository history. > Smaller projects of 1-2 people, we could have gotten away with > asking them to fix their history. > > I guess that answers the questions then. CGit permits this with > a warning, and must always continue to do that. And JGit needs to > fix itself to do the same. >
Wait a minute, something strange is going on here.
My combined kernel repository has 16 of these things according to git-fsck. And when I do 'git-fsck torvalds/linux-2.6/master' I get the same 16 BUT when I 'git-rev-list --objects torvalds/linux-2.6/master' they do not appear in the output.