Jeff King <p...@peff.net> writes: > Broken ident lines are annoying, but not _too_ fundamentally bad. > Duplicate tree entries are a lot worse. Fsck even distinguishes between > "error" and "warning", but "index-pack --strict" treats both as a reason > to reject the object. We could perhaps loosen that, and make sure our > error/warning categories are reasonable.
A pack stream that records the same object twice is not a breakage that is buried deep in the history and cannot be corrected without a wholesale history rewrite, unlike commit objects with broken ident lines or tree objects with 0-filled file type designators. As such, I think it is a reasonable thing to do the following: - "git repack" should be taught to dedup, as a way to recover from such a breakage, if not done already. - "git fsck" should complain, suggesting users to repack to recover. It may even want to exit with non-zero status. - "git receive-pack" and "git fetch-pack" should warn, loudly, without failing. They should ideally not keep such a corrupt pack stream on disk at all, de-duping the objects while streaming, but if that is not practical, at least they should give an easy way for the user to cause de-duping immediately (I do not mind if that is "we detected that the other side fed us a pack stream that is broken. We automatically correct the breakage for you by repacking. Be patient while we do so"). - If the other side of "receive-pack/fetch-pack" implements the agent capability, upon detecting such a breakage, it may not be a bad idea to offer the user to send an e-mail reporting the version of the software to a wall-of-shame e-mail address ;-). I agree that a tree that records the same path twice should be outright rejected. There is no sane recovery path. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
