On Sat, Mar 27, 2010 at 3:14 PM, Shawn O. Pearce <spearce@xxxxxxxxxxx> wrote: > Nicolas Pitre <nico@xxxxxxxxxxx> wrote: >> On Sat, 27 Mar 2010, Scott Chacon wrote: >> > , and the only reason it's an >> > issue at all is that JGit is not following the authoritative CGit >> > implementation of basically ignoring it. >> >> But again CGit's fsck is not ignoring this discrepancy. And if the CGit >> core is otherwise silently accepting it then it is a mistake. > > Right. I tend to agree. CGit was too lax here, fsck shouldn't > be issuing a warning, it should be a fatal error. Both CGit and > JGit are too lax by not failing when reading that tree during > normal processing. Gah, no! Why would you want to make CGit work *less*? Print a warning, sure, but since the tree is perfectly readable, there's no reason to refuse to read it. That's just rude. Similarly, there should be no reason for fsck to treat *any* recoverable error as fatal. If it drops dead, it then misses the chance to diagnose later problems. When I run fsck, I want to see all the problems, not just the first one, especially if the first one can be fixed by filter-branch. Bonus points if (like e2fsck) it offers to fix it for me, though that's probably not worth implementing here. CGit works fine already. The only problem it has is that it works so well that Scott didn't notice his bug. This can be fixed by adding a simple warning. Have fun, Avery -- 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