{"thread":{"id":"34854","subject":"Zero padded file modes...","startedAt":"2013-09-05T14:00:39Z","lastAt":"2013-09-05T19:35:08Z","messageCount":10,"participants":["John Szakmeister","Jeff King","Duy Nguyen","A Large Angry SCM","Nicolas Pitre"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"226850","messageId":"CAEBDL5W3DL0v=TusuB7Vg-4bWdAJh5d2Psc1N0Qe+KK3bZH3=Q@mail.gmail.com","threadId":"34854","inReplyTo":null,"subject":"Zero padded file modes...","fromName":"John Szakmeister","fromEmail":"john@szakmeister.net","sentAt":"2013-09-05T14:00:39Z","receivedAt":"2013-09-05T14:00:39Z","isPatch":false,"sender":{"key":"john@szakmeister.net","avatar":"https://avatars.githubusercontent.com/u/448087?v=4"},"body":"I went to clone a repository from GitHub today and discovered\nsomething interesting:\n\n    :: git clone https://github.com/liebke/incanter.git\n    Cloning into 'incanter'...\n    remote: Counting objects: 10457, done.\n    remote: Compressing objects: 100% (3018/3018), done.\n    error: object 4946e1ba09ba5655202a7a5d81ae106b08411061:contains\nzero-padded file modes\n    fatal: Error in object\n    fatal: index-pack failed\n\nAt first, it surprised me that no one has seen the issue before,\nbut then I remembered I have transfer.fsckObjects=true in my\nconfig.  Turning it off, I was able to clone.  Running `git\nfsck` I see:\n\n    :: git fsck\n    Checking object directories: 100% (256/256), done.\n    warning in tree 4946e1ba09ba5655202a7a5d81ae106b08411061: contains\nzero-padded file modes\n    warning in tree 553c5e006e53a8360126f053c3ade3d1d063c2f5: contains\nzero-padded file modes\n    warning in tree 0a2e7f55d7f8e1fa5469e6d83ff20365881eed1a: contains\nzero-padded file modes\n    Checking objects: 100% (10560/10560), done.\n\nSo there appears to be several instances of the issue in the\ntree.  Looking in the archives, I ran across this thread:\n\n    http://comments.gmane.org/gmane.comp.version-control.git/143288\n\nIn there, Nicolas Pitre says:\n\n> This is going to screw up pack v4 (yes, someday I'll have the\n> time to make it real).\n\nI don't know if this is still true, but given that patches are\nbeing sent out about it, I thought it relevant.\n\nAlso, searching on the issue, you'll find that a number of\nrepositories have suffered from this problem, and it appears the\nonly fix will result in different commit ids.  Given all of\nthat, should Git be updated to cope with zero padded modes?  Or\nis there no some way of fixing the issue that doesn't involve\nchanging commit ids?\n\nThanks!\n\n-John\n"},{"id":"226854","messageId":"20130905153646.GA12372@sigill.intra.peff.net","threadId":"34854","inReplyTo":"CAEBDL5W3DL0v=TusuB7Vg-4bWdAJh5d2Psc1N0Qe+KK3bZH3=Q@mail.gmail.com","subject":"Re: Zero padded file modes...","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-09-05T15:36:46Z","receivedAt":"2013-09-05T15:36:46Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Sep 05, 2013 at 10:00:39AM -0400, John Szakmeister wrote:\n\n> I went to clone a repository from GitHub today and discovered\n> something interesting:\n> \n>     :: git clone https://github.com/liebke/incanter.git\n>     Cloning into 'incanter'...\n>     remote: Counting objects: 10457, done.\n>     remote: Compressing objects: 100% (3018/3018), done.\n>     error: object 4946e1ba09ba5655202a7a5d81ae106b08411061:contains\n> zero-padded file modes\n>     fatal: Error in object\n>     fatal: index-pack failed\n\nYep. These were mostly caused by a bug in Grit that is long-fixed.  But\nthe objects remain in many histories. It would have painful to rewrite\nthem back then, and it would be even more painful now.\n\n> > This is going to screw up pack v4 (yes, someday I'll have the\n> > time to make it real).\n> \n> I don't know if this is still true, but given that patches are\n> being sent out about it, I thought it relevant.\n\nI haven't looked carefully at the pack v4 patches yet, but I suspect\nthat yes, it's still a problem. The premise of pack v4 is that we can do\nbetter by not storing the raw git object bytes, but rather storing\nspecialized representations of the various components. For example, by\nusing an integer to store the mode rather than the ascii representation.\nBut that representation does not represent the \"oops, I have a 0-padded\nmode\" quirk. And we have to be able to recover the original object, byte\nfor byte, from the v4 representation (to verify sha1, or to generate a\nloose object or v2 pack).\n\nThere are basically two solutions:\n\n  1. Add a single-bit flag for \"I am 0-padded in the real data\". We\n     could probably even squeeze it into the same integer.\n\n  2. Have a \"classic\" section of the pack that stores the raw object\n     bytes. For objects which do not match our expectations, store them\n     raw instead of in v4 format. They will not get the benefit of v4\n     optimizations, but if they are the minority of objects, that will\n     only end up with a slight slow-down.\n\nAs I said, I have not looked carefully at the v4 patches, so maybe they\nhandle this case already. But of the two solutions, I prefer (2). Doing\n(1) can solve _this_ problem, but it complicates the format, and does\nnothing for any future compatibility issues. Whereas (2) is easy to\nimplement, since it is basically just pack v2 (and implementations would\nneed a pack v2 reader anyway).\n\n-Peff\n"},{"id":"226856","messageId":"CACsJy8C4PN4n1W71ajnoyFjaWCsxQjbXMbT-tcfgpXeoJKyXyA@mail.gmail.com","threadId":"34854","inReplyTo":"20130905153646.GA12372@sigill.intra.peff.net","subject":"Re: Zero padded file modes...","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2013-09-05T16:18:24Z","receivedAt":"2013-09-05T16:18:24Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Thu, Sep 5, 2013 at 10:36 PM, Jeff King <peff@peff.net> wrote:\n>> > This is going to screw up pack v4 (yes, someday I'll have the\n>> > time to make it real).\n>>\n>> I don't know if this is still true, but given that patches are\n>> being sent out about it, I thought it relevant.\n>\n> I haven't looked carefully at the pack v4 patches yet, but I suspect\n> that yes, it's still a problem. The premise of pack v4 is that we can do\n> better by not storing the raw git object bytes, but rather storing\n> specialized representations of the various components. For example, by\n> using an integer to store the mode rather than the ascii representation.\n> But that representation does not represent the \"oops, I have a 0-padded\n> mode\" quirk. And we have to be able to recover the original object, byte\n> for byte, from the v4 representation (to verify sha1, or to generate a\n> loose object or v2 pack).\n>\n> There are basically two solutions:\n>\n>   1. Add a single-bit flag for \"I am 0-padded in the real data\". We\n>      could probably even squeeze it into the same integer.\n>\n>   2. Have a \"classic\" section of the pack that stores the raw object\n>      bytes. For objects which do not match our expectations, store them\n>      raw instead of in v4 format. They will not get the benefit of v4\n>      optimizations, but if they are the minority of objects, that will\n>      only end up with a slight slow-down.\n\n3. Detect this situation and fall back to v2.\n\n4. Update v4 to allow storing raw tree entries mixing with v4-encoded\ntree entries. This is something between (1) and (2)\n\n> As I said, I have not looked carefully at the v4 patches, so maybe they\n> handle this case already. But of the two solutions, I prefer (2). Doing\n> (1) can solve _this_ problem, but it complicates the format, and does\n> nothing for any future compatibility issues. Whereas (2) is easy to\n> implement, since it is basically just pack v2 (and implementations would\n> need a pack v2 reader anyway).\n\nI think (4) fits better in v4 design and probably not hard to do. Nico\nrecently added a code to embed a tree entry inline, but the mode must\nbe encoded (and can't contain leading zeros). We could have another\ncode to store mode in ascii. This also makes me wonder if we might\nhave similar problems with timezones, which are also specially encoded\nin v4..\n\n(3) is probably easiest. We need to scan through all tree entries\nfirst when creating v4 anyway. If we detect any anomalies, just switch\nback to v2 generation. The user will be force to rewrite history in\norder to take full advantage of v4 (they can have a pack of weird\ntrees in v2 and the rest in v4 pack, but that's not optimal).\n-- \nDuy\n"},{"id":"226857","messageId":"5228B079.9000601@gmail.com","threadId":"34854","inReplyTo":"20130905153646.GA12372@sigill.intra.peff.net","subject":"Re: Zero padded file modes...","fromName":"A Large Angry SCM","fromEmail":"gitzilla@gmail.com","sentAt":"2013-09-05T16:25:29Z","receivedAt":"2013-09-05T16:25:29Z","isPatch":false,"sender":{"key":"gitzilla@gmail.com","avatar":"https://gravatar.com/avatar/354625c442439908ff3dd99757dee330e29e9df7847472384faf7a00add247fb?d=mp&s=160"},"body":"\n\nOn 09/05/2013 11:36 AM, Jeff King wrote:\n[...]\n>\n> I haven't looked carefully at the pack v4 patches yet, but I suspect\n> that yes, it's still a problem. The premise of pack v4 is that we can do\n> better by not storing the raw git object bytes, but rather storing\n> specialized representations of the various components. For example, by\n> using an integer to store the mode rather than the ascii representation.\n> But that representation does not represent the \"oops, I have a 0-padded\n> mode\" quirk. And we have to be able to recover the original object, byte\n> for byte, from the v4 representation (to verify sha1, or to generate a\n> loose object or v2 pack).\n>\n> There are basically two solutions:\n>\n>    1. Add a single-bit flag for \"I am 0-padded in the real data\". We\n>       could probably even squeeze it into the same integer.\n>\n>    2. Have a \"classic\" section of the pack that stores the raw object\n>       bytes. For objects which do not match our expectations, store them\n>       raw instead of in v4 format. They will not get the benefit of v4\n>       optimizations, but if they are the minority of objects, that will\n>       only end up with a slight slow-down.\n>\n> As I said, I have not looked carefully at the v4 patches, so maybe they\n> handle this case already. But of the two solutions, I prefer (2). Doing\n> (1) can solve _this_ problem, but it complicates the format, and does\n> nothing for any future compatibility issues. Whereas (2) is easy to\n> implement, since it is basically just pack v2 (and implementations would\n> need a pack v2 reader anyway).\n\n3. Keep those objects in v2 packs instead of the v4 pack. Transfers \nwould have to be v3 or multi-pack transfers would need to be supported.\n\n4. Don't use v4 packs with projects that have \"crufty\" objects. Projects \nwith such objects may choose to pay the \"cost\" to \"upgrade\" to v4 \ncompatibility.\n\nThere's nothing that requires the next pack format to support all of the \nbroken stuff that's happened over the years.\n"},{"id":"226858","messageId":"20130905163318.GA14338@sigill.intra.peff.net","threadId":"34854","inReplyTo":"CACsJy8C4PN4n1W71ajnoyFjaWCsxQjbXMbT-tcfgpXeoJKyXyA@mail.gmail.com","subject":"Re: Zero padded file modes...","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-09-05T16:33:18Z","receivedAt":"2013-09-05T16:33:18Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Sep 05, 2013 at 11:18:24PM +0700, Nguyen Thai Ngoc Duy wrote:\n\n> > There are basically two solutions:\n> >\n> >   1. Add a single-bit flag for \"I am 0-padded in the real data\". We\n> >      could probably even squeeze it into the same integer.\n> >\n> >   2. Have a \"classic\" section of the pack that stores the raw object\n> >      bytes. For objects which do not match our expectations, store them\n> >      raw instead of in v4 format. They will not get the benefit of v4\n> >      optimizations, but if they are the minority of objects, that will\n> >      only end up with a slight slow-down.\n> \n> 3. Detect this situation and fall back to v2.\n> \n> 4. Update v4 to allow storing raw tree entries mixing with v4-encoded\n> tree entries. This is something between (1) and (2)\n\nI wouldn't want to do (3). At some point pack v4 may become the standard\nformat, but there will be some repositories which will never be allowed\nto adopt it.\n\nFor (4), yes, that could work. But like (1), it only solves problems in\ntree entries. What happens if we have a quirky commit object that needs\nthe same treatment (e.g., a timezone that does not fit into the commit\nname dictionary properly)?\n\n> I think (4) fits better in v4 design and probably not hard to do. Nico\n> recently added a code to embed a tree entry inline, but the mode must\n> be encoded (and can't contain leading zeros). We could have another\n> code to store mode in ascii. This also makes me wonder if we might\n> have similar problems with timezones, which are also specially encoded\n> in v4..\n\nYeah, that might be more elegant.\n\n> (3) is probably easiest. We need to scan through all tree entries\n> first when creating v4 anyway. If we detect any anomalies, just switch\n> back to v2 generation. The user will be force to rewrite history in\n> order to take full advantage of v4 (they can have a pack of weird\n> trees in v2 and the rest in v4 pack, but that's not optimal).\n\nSplitting across two packs isn't great, though. What if v4 eventually\nbecomes the normal on-the-wire format? I'd rather have some method for\njust embedding what are essentially v2 objects into the v4 pack, which\nwould give us future room for handling these sorts of things.\n\nBut like I said, I haven't looked closely yet, so maybe there are\ncomplications with that. In the meantime, I'll defer to the judgement of\npeople who know what they are talking about. :)\n\n-Peff\n"},{"id":"226860","messageId":"alpine.LFD.2.03.1309051244160.14472@syhkavp.arg","threadId":"34854","inReplyTo":"20130905163318.GA14338@sigill.intra.peff.net","subject":"Re: Zero padded file modes...","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2013-09-05T16:56:29Z","receivedAt":"2013-09-05T16:56:29Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 5 Sep 2013, Jeff King wrote:\n\n> On Thu, Sep 05, 2013 at 11:18:24PM +0700, Nguyen Thai Ngoc Duy wrote:\n> \n> > > There are basically two solutions:\n> > >\n> > >   1. Add a single-bit flag for \"I am 0-padded in the real data\". We\n> > >      could probably even squeeze it into the same integer.\n> > >\n> > >   2. Have a \"classic\" section of the pack that stores the raw object\n> > >      bytes. For objects which do not match our expectations, store them\n> > >      raw instead of in v4 format. They will not get the benefit of v4\n> > >      optimizations, but if they are the minority of objects, that will\n> > >      only end up with a slight slow-down.\n> > \n> > 3. Detect this situation and fall back to v2.\n> > \n> > 4. Update v4 to allow storing raw tree entries mixing with v4-encoded\n> > tree entries. This is something between (1) and (2)\n> \n> I wouldn't want to do (3). At some point pack v4 may become the standard\n> format, but there will be some repositories which will never be allowed\n> to adopt it.\n> \n> For (4), yes, that could work. But like (1), it only solves problems in\n> tree entries. What happens if we have a quirky commit object that needs\n> the same treatment (e.g., a timezone that does not fit into the commit\n> name dictionary properly)?\n> \n> > I think (4) fits better in v4 design and probably not hard to do. Nico\n> > recently added a code to embed a tree entry inline, but the mode must\n> > be encoded (and can't contain leading zeros). We could have another\n> > code to store mode in ascii. This also makes me wonder if we might\n> > have similar problems with timezones, which are also specially encoded\n> > in v4..\n> \n> Yeah, that might be more elegant.\n> \n> > (3) is probably easiest. We need to scan through all tree entries\n> > first when creating v4 anyway. If we detect any anomalies, just switch\n> > back to v2 generation. The user will be force to rewrite history in\n> > order to take full advantage of v4 (they can have a pack of weird\n> > trees in v2 and the rest in v4 pack, but that's not optimal).\n> \n> Splitting across two packs isn't great, though. What if v4 eventually\n> becomes the normal on-the-wire format? I'd rather have some method for\n> just embedding what are essentially v2 objects into the v4 pack, which\n> would give us future room for handling these sorts of things.\n> \n> But like I said, I haven't looked closely yet, so maybe there are\n> complications with that. In the meantime, I'll defer to the judgement of\n> people who know what they are talking about. :)\n\nNone of the above is particularly appealing to me.\n\nPack v4 has to enforce some standardization in the object encoding to be \nefficient.  Some compromizes have been applied to accommodate the fixing \nof a thin pack, although I was initially tempted to simply dodge the \nissue and allow thin packs in a repository.\n\nOn this particular mode issue, I remember making a fuss at the time when \nthis was discovered because the github implementation did generate such \ntree objects at the time.\n\nSo instead of compromizing the pack v4 object encoding further, I'd \nsimply suggest adding a special object type which is in fact simply the \npack v2 representation i.e. the canonical object version, deflated.  \nRight now pack v4 encodes only 5 object types: commit, tree, blob, delta \nand tag.  Only the commit and tree objects have their representation \ntranscoded.  So that means we only need to add native_commit and \nnative_tree object types.\n\nThen, anything that doesn't fit the strict expectation for transcoding a \ntree or a commit object is simply included as is without transcoding \njust like in pack v2.\n\n\nNicolas\n"},{"id":"226861","messageId":"alpine.LFD.2.03.1309051302570.14472@syhkavp.arg","threadId":"34854","inReplyTo":"20130905153646.GA12372@sigill.intra.peff.net","subject":"Re: Zero padded file modes...","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2013-09-05T17:09:34Z","receivedAt":"2013-09-05T17:09:34Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 5 Sep 2013, Jeff King wrote:\n\n> There are basically two solutions:\n> \n>   1. Add a single-bit flag for \"I am 0-padded in the real data\". We\n>      could probably even squeeze it into the same integer.\n> \n>   2. Have a \"classic\" section of the pack that stores the raw object\n>      bytes. For objects which do not match our expectations, store them\n>      raw instead of in v4 format. They will not get the benefit of v4\n>      optimizations, but if they are the minority of objects, that will\n>      only end up with a slight slow-down.\n\nThat is basically what I just suggested.  But instead of a special \nsection, simply using a special object type number would do it.\n\nI'm even wondering if that couldn't be used for fixing a thin pack \ninstead of the special provision I just added last night.\n\n\nNicolas\n"},{"id":"226862","messageId":"CAEBDL5UiEurFeZg1AuNUKEvBMDs3K3D5ZiF5rB-dYWjp5nvrEA@mail.gmail.com","threadId":"34854","inReplyTo":"20130905153646.GA12372@sigill.intra.peff.net","subject":"Re: Zero padded file modes...","fromName":"John Szakmeister","fromEmail":"john@szakmeister.net","sentAt":"2013-09-05T17:13:40Z","receivedAt":"2013-09-05T17:13:40Z","isPatch":false,"sender":{"key":"john@szakmeister.net","avatar":"https://avatars.githubusercontent.com/u/448087?v=4"},"body":"On Thu, Sep 5, 2013 at 11:36 AM, Jeff King <peff@peff.net> wrote:\n> On Thu, Sep 05, 2013 at 10:00:39AM -0400, John Szakmeister wrote:\n>\n>> I went to clone a repository from GitHub today and discovered\n>> something interesting:\n>>\n>>     :: git clone https://github.com/liebke/incanter.git\n>>     Cloning into 'incanter'...\n>>     remote: Counting objects: 10457, done.\n>>     remote: Compressing objects: 100% (3018/3018), done.\n>>     error: object 4946e1ba09ba5655202a7a5d81ae106b08411061:contains\n>> zero-padded file modes\n>>     fatal: Error in object\n>>     fatal: index-pack failed\n>\n> Yep. These were mostly caused by a bug in Grit that is long-fixed.  But\n> the objects remain in many histories. It would have painful to rewrite\n> them back then, and it would be even more painful now.\n\nI guess there's still the other side of the question though.  Are\nthese repositories busted in the sense that something no longer works?\n I doesn't appear to be the case, but I've not used it extensively say\nI can't say for certain one way or another.  In the sense that the\ncontent is not strictly compliant, transfer.fsckObjects did its job,\nbut I wonder if fsck needs to be a little more tolerant now (at least\nwith respect to transfer objects)?\n\nI can certainly cope with the issue--it's not a problem for me to flip\nthe flag on the command line.  I think it'd be nice to have\ntranser.fsckObjects be the default at some point, considering how\nlittle people run fsck otherwise and how long these sorts of issues go\nundiscovered.  Issues like the above seem to stand in the way of that\nhappening though.\n\n-John\n"},{"id":"226872","messageId":"20130905191038.GA15910@sigill.intra.peff.net","threadId":"34854","inReplyTo":"alpine.LFD.2.03.1309051302570.14472@syhkavp.arg","subject":"Re: Zero padded file modes...","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-09-05T19:10:38Z","receivedAt":"2013-09-05T19:10:38Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Sep 05, 2013 at 01:09:34PM -0400, Nicolas Pitre wrote:\n\n> On Thu, 5 Sep 2013, Jeff King wrote:\n> \n> > There are basically two solutions:\n> > \n> >   1. Add a single-bit flag for \"I am 0-padded in the real data\". We\n> >      could probably even squeeze it into the same integer.\n> > \n> >   2. Have a \"classic\" section of the pack that stores the raw object\n> >      bytes. For objects which do not match our expectations, store them\n> >      raw instead of in v4 format. They will not get the benefit of v4\n> >      optimizations, but if they are the minority of objects, that will\n> >      only end up with a slight slow-down.\n> \n> That is basically what I just suggested.  But instead of a special \n> section, simply using a special object type number would do it.\n\nYeah, I think we are in agreement. I only suggested a separate section\nbecause I hadn't carefully read the v4 patches yet, and didn't know if\nthere was room in the normal sequence. A special object number seems\nmuch more elegant.\n\n-Peff\n"},{"id":"226877","messageId":"20130905193507.GB15910@sigill.intra.peff.net","threadId":"34854","inReplyTo":"CAEBDL5UiEurFeZg1AuNUKEvBMDs3K3D5ZiF5rB-dYWjp5nvrEA@mail.gmail.com","subject":"Re: Zero padded file modes...","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-09-05T19:35:08Z","receivedAt":"2013-09-05T19:35:08Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Sep 05, 2013 at 01:13:40PM -0400, John Szakmeister wrote:\n\n> > Yep. These were mostly caused by a bug in Grit that is long-fixed.  But\n> > the objects remain in many histories. It would have painful to rewrite\n> > them back then, and it would be even more painful now.\n> \n> I guess there's still the other side of the question though.  Are\n> these repositories busted in the sense that something no longer works?\n\nNo, as far as I know, everything still works fine. However, some diffs\nmay be suboptimal, because we may have two different sha1s for the same\nsubtree (so we may descend into the tree unnecessarily only to find that\nthey are equivalent). And by the same token, any scripts doing\nnon-recursive diffs may erroneously mark the trees as differing, even\nthough they do not contain any differing files.\n\nBut neither is a big problem in practice. If you had two clients in\nactive use which were flip-flopping a sub-tree back and forth between\nrepresentations, it would be a problem. But we are talking about a few\nisolated incidents far back in history.\n\n> I doesn't appear to be the case, but I've not used it extensively say\n> I can't say for certain one way or another.  In the sense that the\n> content is not strictly compliant, transfer.fsckObjects did its job,\n> but I wonder if fsck needs to be a little more tolerant now (at least\n> with respect to transfer objects)?\n\nFsck actually treats this as a warning, not an error. It is\ntransfer.fsckObjects (via \"index-pack --strict\") that actually treats\nwarnings as errors.\n\nIt's possible that this should be loosened to allow through problems\nmarked as FSCK_WARN (with a message, kind of like...a warning). Though\nit may also make sense to revisit some of the classifications in fsck\n(e.g., many of the warnings are indicative of seriously broken objects).\n\nGitHub uses transfer.fsckObjects, rejecting all warnings[1]. In practice\nit is not usually a big deal, as people are happy to fix up their\nobjects _before_ they get widely published. The biggest push-back we get\nis when somebody tries to re-push history they got from another GitHub\nrepo, and then says \"But why are you complaining? You served this crappy\nbroken history?\" And it's a fair point. If you are forking (but not\njoining the existing fork network) of an existing project with\nirregularities in the history, it's not really an option to simply\nrewrite the history you are basing on.\n\n-Peff\n\n[1] Actually, we do let through 0-padded modes with a warning,\n    explicitly because of the problem mentioned above.\n"}]}