"Shawn O. Pearce" <spearce@xxxxxxxxxxx> writes: > Scott, please fix that library on GitHub. JGit's fsck has a hard > failure on these malformed trees, because the leading '0' mode > causes the tree to come up with the wrong SHA-1 hash given its > logical content. They shouldn't be created like this. What is curious is that even though 6407180 (git-fsck-cache: be stricter about "tree" objects, 2005-07-27) does talk about zero-padding, it appears that we never had a version of git that padded mode in '0' in the entire history of write-tree (except that "notes tree" one, but even that didn't escape the laboratory). But now we know there is a tool in the wild creating broken objects left and right, jgit's fsck routine might need to be more lenient (while warning loudly) in what it accepts. Scott, does your tool have outside users (i.e. being freely distributed and you have no control over the continued use of existing copies that create broken objects)? If not, then there won't be further damage once you fix it at Github, and we may not have to worry about changing jgit after all. -- 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