A Large Angry SCM wrote:
A Large Angry SCM wrote:
Shawn O. Pearce wrote:
A Large Angry SCM <gitzilla@xxxxxxxxx> 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.
Ignore my noise until some more checking is done!
My combined repository also includes Scott's progit book and examples
repositories. I'm guessing that git-fsck did not limit itself to just
the object reachable from the torvalds/linux-2.6/master ref.
The 16 offending trees are all git-rev-list reachable from Scott's
progit book master ref and _NOT_ from Linus' Linux master ref.
Sorry about the confusion!!!
--
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