Hi, Jonathan Nieder writes: > Ramkumar Ramachandra wrote: >> [Subject: [PATCH 03/18] revert: Simplify and inline add_message_to_msg] > > Before, I wrote that it would be better to present this as a bugfix > than as a code reorganization, since the former is more likely to > affect people upgrading or to be relevant if this later turns out to > have a regression and someone wonders why not to just revert it. Was > I wrong? I like the new commit message: I like to think that the old code was misguided (intent: replace an empty commit message with the commit object name), rather than buggy. Since it's not possible to reproduce the "bug" without constructing a commit object by hand, I don't know if we should classify it a "bug". > Testcase below. It makes a commit like this: > > tree f0db5ba931b3f121d2050e23ac3cd47ac2233306 > parent 43991719f0536a734e91e94f40361114477b3b5e > author A U Thor <author@xxxxxxxxxxx> 1112912113 -0700 > committer C O Mitter <committer@xxxxxxxxxxx> 1112912113 -0700 > > with no blank line afterwards. I think this is relevant and not a > "what if cosmic rays corrupt that pointer" kind of thing because > people use non-git programs or libraries to write to git object stores > pretty often. If this object were invalid, it would still not be a > good behavior to segfault (better to die() or give some > arbitrary-but-sane result). Not sure whether the object should be > considered invalid (e.g., "git fsck" accepts it). Thanks for writing the test. However, there are probably several other edge cases in other parts of Git which accept slightly malformed tree/ blob objects. Including this test is like telling developers: "We have to be prepared for the worst kind of malformed objects in every single Git application, not just objects created by us", and there is probably no end to this. In my opinion, it is alright to SIGSEGV when a different but incorrect implementation of Git creates a corrupt object store -- we should punish them for the mistake and set an example. Instead of attacking the problem at this level, I think we should get the lower layers like git-fsck to throw out malformed objects. > Unfortunately it fails for me even after the patch. If the test looks > reasonable to you, it could be worth adding marked with > "test_expect_failure". Perhaps as part of a different series which addresses the issue of malformed objects in general. I don't think it is relevant for this series. The "other" series I'm thinking about should contain: 1. Documentation about the exact format of commit, tree, blob objects the way the fast-import stream is documented. 2. Fixes to the lower layers like git fsck/repack/gc: it should throw out objects that don't conform to the spec. 3. A dedicated list of tests that intentionally create malformed objects to verify the spec/ restraining code. (It should accommodate the major implementations and older versions of C Git) Thanks. -- Ram -- 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