{"thread":{"id":"39475","subject":"git gc gives \"error: Could not read...\"","startedAt":"2015-06-01T07:37:17Z","lastAt":"2015-06-01T16:11:56Z","messageCount":15,"participants":["Stefan Näwe","Jeff King","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"262559","messageId":"556C0BAD.80106@atlas-elektronik.com","threadId":"39475","inReplyTo":null,"subject":"git gc gives \"error: Could not read...\"","fromName":"Stefan Näwe","fromEmail":"stefan.naewe@atlas-elektronik.com","sentAt":"2015-06-01T07:37:17Z","receivedAt":"2015-06-01T07:37:17Z","isPatch":false,"sender":{"key":"stefan.naewe@gmail.com","avatar":"https://avatars.githubusercontent.com/u/4468?v=4"},"body":"Hi there.\n\nOne of my repos started giving an error on 'git gc' recently:\n\n $ git gc\n error: Could not read 7713c3b1e9ea2dd9126244697389e4000bb39d85\n Counting objects: 3052, done.\n Delta compression using up to 4 threads.\n Compressing objects: 100% (531/531), done.\n Writing objects: 100% (3052/3052), done.\n Total 3052 (delta 2504), reused 3052 (delta 2504)\n error: Could not read 7713c3b1e9ea2dd9126244697389e4000bb39d85\n\n(Yes, the error comes twice).\n\nI tried:\n\n $ git cat-file -t 7713c3b1e9ea2dd9126244\n fatal: Not a valid object name 7713c3b1e9ea2dd9126244\n\n\nOtherwise, everything works fine.\n\nI used that repo initially on Win7 with an older msysgit installation but\nalso tried the latest git-for-windows installer, and version 2.4.2 on linux.\nAll give the same error (no matter if I clone or copy the repo).\n\nUnfortunately I cannot make the repo publically available.\n\nAny chance to get rid of that error ?\n\nThanks,\n  Stefan\n-- \n----------------------------------------------------------------\n/dev/random says: When it comes to humility, I'm the very BEST there is!\npython -c \"print '73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')\" \nGPG Key fingerprint = 2DF5 E01B 09C3 7501 BCA9  9666 829B 49C5 9221 27AF\n"},{"id":"262561","messageId":"20150601081450.GA32634@peff.net","threadId":"39475","inReplyTo":"556C0BAD.80106@atlas-elektronik.com","subject":"Re: git gc gives \"error: Could not read...\"","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-06-01T08:14:50Z","receivedAt":"2015-06-01T08:14:50Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jun 01, 2015 at 09:37:17AM +0200, Stefan Näwe wrote:\n\n> One of my repos started giving an error on 'git gc' recently:\n> \n>  $ git gc\n>  error: Could not read 7713c3b1e9ea2dd9126244697389e4000bb39d85\n>  Counting objects: 3052, done.\n>  Delta compression using up to 4 threads.\n>  Compressing objects: 100% (531/531), done.\n>  Writing objects: 100% (3052/3052), done.\n>  Total 3052 (delta 2504), reused 3052 (delta 2504)\n>  error: Could not read 7713c3b1e9ea2dd9126244697389e4000bb39d85\n\nThe only error string that matches that is the one in parse_commit(),\nwhen we fail to read the object. It happens twice here because\n`git gc` runs several subcommands; you can see which ones are generating\nthe error if you run with GIT_TRACE=1.\n\nI am surprised that it doesn't cause the commands to abort, though. If\nwe are traversing the object graph to repack, for example, we would want\nto abort if we are missing a reachable object (i.e., the repository is\ncorrupt).\n\n> I tried:\n> \n>  $ git cat-file -t 7713c3b1e9ea2dd9126244\n>  fatal: Not a valid object name 7713c3b1e9ea2dd9126244\n\nNot surprising, if we don't have the object. What is curious is why git\nwants to look it up in the first place. I.e., who is referencing it?\n\nEither:\n\n  1. It is an object that we are OK to be missing (e.g., the\n     UNINTERESTING side of a traversal), and the error should be\n     suppressed.\n\n  2. Your repository really is corrupted, and this is a case where we\n     need to be paying attention to the return value of parse_commit but\n     are not.\n\nI'd love to see:\n\n  - the output of \"GIT_TRACE=1 git gc\" (to see which subcommand is\n    causing the error)\n\n  - the output of \"git fsck\" (which should hopefully confirm whether or\n    not there is a real problem)\n\n  - any mentions of the sha1 in the refs or reflogs. Something like:\n\n      sha1=7713c3b1e9ea2dd9126244697389e4000bb39d85\n      cd .git\n      grep $sha1 $(find packed-refs refs logs -type f)\n\n  - If that doesn't turn up any hits, then presumably it's an object\n    referencing the sha1. We can dig into the objects (all of them, not\n    just reachable ones), like:\n\n      {\n        # loose objects\n        (cd .git/objects && find ?? -type f | tr -d /)\n        # packed objects\n        for i in .git/objects/pack/*.idx; do\n          git show-index <$i\n        done | cut -d' ' -f2\n      } |\n      # omit blobs; they are expensive to access and cannot have\n      # reachability pointers\n      git cat-file --batch-check='%(objecttype) %(objectname)' |\n      grep -v ^blob |\n      cut -d' ' -f2 |\n      # now get all of the contents, and look for our object; this is\n      # going to be slow, since it's one process per object; but we\n      # can't use --batch because we need to pretty-print the trees\n      xargs -n1 git cat-file -p |\n      less +/$sha1\n\nI would have guessed this was maybe caused by trying to traverse\nunreachable recent objects for reachability. It fits case 1 (it is OK\nfor us to be missing these objects, but we might accidentally complain),\nand it would probably happen twice during a gc (once for the repack, and\nonce for `git prune`).\n\nBut that code should not be present in older versions of msysgit, as it\ncame in v2.2.0 (and I assume \"older msysgit is v1.9.5). And if that is\nthe problem, it would follow a copy of the repo, but not a clone (though\nI guess if your clone was on the local filesystem, we blindly hardlink\nthe objects, so it might follow there).\n\n-Peff\n"},{"id":"262562","messageId":"556C1A95.9010704@atlas-elektronik.com","threadId":"39475","inReplyTo":"20150601081450.GA32634@peff.net","subject":"Re: git gc gives \"error: Could not read...\"","fromName":"Stefan Näwe","fromEmail":"stefan.naewe@atlas-elektronik.com","sentAt":"2015-06-01T08:40:53Z","receivedAt":"2015-06-01T08:40:53Z","isPatch":false,"sender":{"key":"stefan.naewe@gmail.com","avatar":"https://avatars.githubusercontent.com/u/4468?v=4"},"body":"Am 01.06.2015 um 10:14 schrieb Jeff King:\n> On Mon, Jun 01, 2015 at 09:37:17AM +0200, Stefan Näwe wrote:\n> \n>> One of my repos started giving an error on 'git gc' recently:\n>>\n>>  $ git gc\n>>  error: Could not read 7713c3b1e9ea2dd9126244697389e4000bb39d85\n>>  Counting objects: 3052, done.\n>>  Delta compression using up to 4 threads.\n>>  Compressing objects: 100% (531/531), done.\n>>  Writing objects: 100% (3052/3052), done.\n>>  Total 3052 (delta 2504), reused 3052 (delta 2504)\n>>  error: Could not read 7713c3b1e9ea2dd9126244697389e4000bb39d85\n> \n> The only error string that matches that is the one in parse_commit(),\n> when we fail to read the object. It happens twice here because\n> `git gc` runs several subcommands; you can see which ones are generating\n> the error if you run with GIT_TRACE=1.\n> \n> I am surprised that it doesn't cause the commands to abort, though. If\n> we are traversing the object graph to repack, for example, we would want\n> to abort if we are missing a reachable object (i.e., the repository is\n> corrupt).\n> \n>> I tried:\n>>\n>>  $ git cat-file -t 7713c3b1e9ea2dd9126244\n>>  fatal: Not a valid object name 7713c3b1e9ea2dd9126244\n> \n> Not surprising, if we don't have the object. What is curious is why git\n> wants to look it up in the first place. I.e., who is referencing it?\n> \n> Either:\n> \n>   1. It is an object that we are OK to be missing (e.g., the\n>      UNINTERESTING side of a traversal), and the error should be\n>      suppressed.\n> \n>   2. Your repository really is corrupted, and this is a case where we\n>      need to be paying attention to the return value of parse_commit but\n>      are not.\n> \n> I'd love to see:\n> \n>   - the output of \"GIT_TRACE=1 git gc\" (to see which subcommand is\n>     causing the error)\n> \n>   - the output of \"git fsck\" (which should hopefully confirm whether or\n>     not there is a real problem)\n\nSee attached file.\n\n>   - any mentions of the sha1 in the refs or reflogs. Something like:\n> \n>       sha1=7713c3b1e9ea2dd9126244697389e4000bb39d85\n>       cd .git\n>       grep $sha1 $(find packed-refs refs logs -type f)\n\nThat gives nothing.\n\n>   - If that doesn't turn up any hits, then presumably it's an object\n>     referencing the sha1. We can dig into the objects (all of them, not\n>     just reachable ones), like:\n> \n>       {\n>         # loose objects\n>         (cd .git/objects && find ?? -type f | tr -d /)\n>         # packed objects\n>         for i in .git/objects/pack/*.idx; do\n>           git show-index <$i\n>         done | cut -d' ' -f2\n>       } |\n>       # omit blobs; they are expensive to access and cannot have\n>       # reachability pointers\n>       git cat-file --batch-check='%(objecttype) %(objectname)' |\n>       grep -v ^blob |\n>       cut -d' ' -f2 |\n>       # now get all of the contents, and look for our object; this is\n>       # going to be slow, since it's one process per object; but we\n>       # can't use --batch because we need to pretty-print the trees\n>       xargs -n1 git cat-file -p |\n>       less +/$sha1\n\nTurns out to be a tree:\n\ntree 7713c3b1e9ea2dd9126244697389e4000bb39d85\nparent d7acfc22fbc0fba467d82f41c90aab7d61f8d751\nauthor Stefan Naewe <stefan.naewe@atlas-elektronik.com> 1429536806 +0200\ncommitter Stefan Naewe <stefan.naewe@atlas-elektronik.com> 1429536806 +0200\n\n\n> I would have guessed this was maybe caused by trying to traverse\n> unreachable recent objects for reachability. It fits case 1 (it is OK\n> for us to be missing these objects, but we might accidentally complain),\n> and it would probably happen twice during a gc (once for the repack, and\n> once for `git prune`).\n> \n> But that code should not be present in older versions of msysgit, as it\n> came in v2.2.0 (and I assume \"older msysgit is v1.9.5). \n\nNot exactly. My msysgit is merge-rebase'd (or rebase-merge'd...) onto v2.2.0...\nI'll try older versions (pre v2.2.0) on linux.\n\n> And if that is\n> the problem, it would follow a copy of the repo, but not a clone (though\n> I guess if your clone was on the local filesystem, we blindly hardlink\n> the objects, so it might follow there).\n\nI also cloned from local filesystem (widnows drive) to a samba share.\n\nThanks,\n  Stefan\n-- \n----------------------------------------------------------------\n/dev/random says: Useless Invention: How-to cassettes for the deaf.\npython -c \"print '73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')\" \nGPG Key fingerprint = 2DF5 E01B 09C3 7501 BCA9  9666 829B 49C5 9221 27AF\n\n\n$ GIT_TRACE=1 git gc\n10:21:27.228845 git.c:348               trace: built-in: git 'gc'\n10:21:27.228845 run-command.c:347       trace: run_command: 'pack-refs' '--all' '--prune'\n10:21:27.244445 git.c:348               trace: built-in: git 'pack-refs' '--all' '--prune'\n10:21:27.260045 run-command.c:347       trace: run_command: 'reflog' 'expire' '--all'\n10:21:27.275646 git.c:348               trace: built-in: git 'reflog' 'expire' '--all'\n10:21:27.338047 run-command.c:347       trace: run_command: 'repack' '-d' '-l' '-A' '--unpack-unreachable=2.weeks.ago'\n10:21:27.353647 git.c:348               trace: built-in: git 'repack' '-d' '-l' '-A' '--unpack-unreachable=2.weeks.ago'\n10:21:27.353647 run-command.c:347       trace: run_command: 'pack-objects' '--keep-true-parents' '--honor-pack-keep' '--non-empty' '--all' '--reflog' '--indexed-objects' '--unpack-unreachable=2.weeks.ago' '--local' '--delta-base-offset' '.git/objects/pack/.tmp-3852-pack'\n10:21:27.384848 git.c:348               trace: built-in: git 'pack-objects' '--keep-true-parents' '--honor-pack-keep' '--non-empty' '--all' '--reflog' '--indexed-objects' '--unpack-unreachable=2.weeks.ago' '--local' '--delta-base-offset' '.git/objects/pack/.tmp-3852-pack'\nerror: Could not read 7713c3b1e9ea2dd9126244697389e4000bb39d85\n10:21:27.915258 run-command.c:347       trace: run_command: 'prune' '--expire' '2.weeks.ago'\n10:21:27.930858 git.c:348               trace: built-in: git 'prune' '--expire' '2.weeks.ago'\nerror: Could not read 7713c3b1e9ea2dd9126244697389e4000bb39d85\n10:21:28.196063 run-command.c:347       trace: run_command: 'rerere' 'gc'\n10:21:28.211664 git.c:348               trace: built-in: git 'rerere' 'gc'\n$ -----------------------------------------------------------------------------\n$ git fsck\ndangling commit 8a0066c756e13e5f8b02fdab4716bff74de7556e\ndangling commit 450111131bb54c2a7426c7c4d07729d96a3a4b08\ndangling blob e6c1f0b06d7c2571f27885efb722628a5640f5bb\ndangling blob ad026f17ef3ca76c8e6a176b0e9c161820cb55bd\ndangling commit bb828e3aea9cd8ca472b7bf84175c2d786c6bca6\ndangling blob cf82a18977b340e8d52f0e7d5a27cc95de79083e\ndangling commit e822f5fd21cb7c0523d73474d7fd5f7038c53323\ndangling blob 132355dd750c3425f566db4df93d11dd5713ee57\ndangling blob 3ba352808438fbcb937efbfe297572e5629622be\ndangling blob 3f6315e9789309b0b608e130d863b99bbf479ea4\ndangling commit 902399eb3d16606940c373340ab287693981094d\ndangling blob d6c30db3396fd157f9051068f85e57b9c0eec5d6\ndangling blob 3344fa068975a3b5f8bbb00161367fd5cfe75c56\ndangling blob 5ea460158d22979898e8c72650c98074d3f9f9d7\ndangling blob dd247bd0e183903e80c634e3d97d757902c19829\ndangling commit 78859135a46bbde0bfd54add4138d6492cf1509a\ndangling blob 84e5b7254a52115ade3f11fcdc39ad3d9480af5a\ndangling blob b085bbf3b6a3021fd28ff54f102aef90bae41ffb\ndangling blob dac51e999c3820142c4b7ecffc7a8249e1d83c31\ndangling commit 8ae6f24c2f6f1e0494a95020131d7c326bc74a4d\ndangling blob 93a6270236e39959b4e1a1bb4996a49819bd8bb8\ndangling blob 7ee7c42e98e64a253e5183b7a0fb0d5fe8ac62d4\ndangling blob a1e7795049e459db59cb897422d6b5b9284f02c4\ndangling commit 1508fa2bb1beba32ce97d9fe52ba41f162cd2a52\ndangling blob 35e85b19da57331a6dff5da3f98dbcba00b1f5cf\ndangling commit 3d8856caf448bf6fd8f255531cd242e937cfe60e\ndangling blob 88e898403686622bee2f5a56e1dcabd3f3e76d7f\ndangling commit fb68819d653555456a1c8a69adfed59b8714fdcb\ndangling commit 66095370ee7c01f97e55bbafb46173d46324d566\ndangling blob 7109dbbb65382961bad78e96e759dc10c6089893\ndangling blob 432a66e07bc0c72b11666ca428e4c144664b8d9d\ndangling commit ae4a91c13b448c1e0df3ea5a490eaadd295b775d\ndangling blob 212bcc5073d3f15d554c57c586607b176999fa6e\ndangling blob 374b9ffcec1d3c0526ac280b3e23019995577229\ndangling blob 75abddbc662d2ad4116cfd1d1b4652a28cdf7516\ndangling commit 136c216120c7c6d562e67ef6a26e118f3d377d75\ndangling blob b48c13bf7ab920fe9d6dae3dd4960616e146e2c4\ndangling blob 12cd4bf13c90918841acde16a84c129f4fe4c1cb\ndangling blob 448e6eca0bdd9070628fe98a3b13af3542eeb190\ndangling blob af8e10f66a96920f9caf7abc7e778a8ed25b7e7f\ndangling blob 2f2fe720093863e455fd350982d22013268db4ab\ndangling blob 786fd76d6e90bd0f812685bcf21308f469cff806\ndangling commit b8cf8a7c3382ae243e3691de437c179f6fe5b109\ndangling commit deef19eb8b606899d18a77e5671569ee422e5c74\ndangling blob c01002da12138b843efc3794ae057828d57713ff\ndangling blob 6e31e31e214628f5cfb208b09f4c8cb6e0a7efd7\ndangling commit c01168eb4f10937347035388e82c34b36b5e757a\ndangling commit c5f1e1f2a04bd46f0f0017be6dbfe39170dacd37\ndangling commit c671700332dac70cb8f02b49d49085635db829b7\ndangling commit c7b16704a89c5e6dff26251c5c3c3596643a4765\ndangling blob 13d2cdca94567550f5720d7271404d5cf1465b76\ndangling blob 7a9216bd39c0249267da24e374b93b0bef7bab3a\ndangling blob e272943ad649011749d99a102f75cbb2cfe0481c\ndangling blob e412a8d9f91ac5ab621c607e9e79dd070f0575ea\ndangling blob 15d3e1c23d11963494f1fddffdfbe8d82281ebe7\ndangling blob dcb3ece673bd71b2a7cd797863ab05b9f55d982a\ndangling blob e893edce44198fc3ed7d2a0a800addb9f7fcdd00\ndangling commit 2c74dba4cb87622bf281fea95495580ed7169f7f\ndangling commit 38349ee95d761badfb6ef86899744ffa7aa6dc4d\ndangling commit 3b348f3eae0e14cdaf792ea11334f1ea20b8ac21\ndangling commit 5874ff569260833b7da14565c9a04172f45bea34\ndangling blob 86d47d16d7cf6b460ff7f2d821845add385b168a\ndangling blob 8e14d0376ae4c963654038ab8552c14a88c82f19\ndangling commit 9674dae0470e1659d08d7258fc87ccb65469c377\ndangling commit a894434804e644d52f18eac6564b5470c355a0fd\ndangling commit fdf458b7ffa6f81038988818f6bdb148ddbd2747\ndangling blob 1a154456fd202678d09c8fe3488a7ff5eb128f0e\ndangling commit 315500c96a705a19bda551b552bb4af76a5423b9\ndangling blob 35d541a16983732fb33205711a4ae275659f35bf\ndangling blob a7354d59cd449515daf1da563d4a81b0511e43f7\ndangling commit bfb5538171c1a00a09b979005a032400b8be6c11\ndangling blob da35f034d130a0d5a7864b243e919c2885af7dcb\ndangling commit 25365b87e74792bd278afec51afdfc74ef378301\ndangling blob 9f36254fdae6ed8e543d8ada1dfeb7273322421f\ndangling commit 82375e755bebab8b4a5c34cc227fdfbcaf587878\ndangling commit 1f78f76aeb42cdd5e7dd5201eb46f11b1794b959\ndangling commit 4418d11dc76a4eb0327c2f182c40584774f1fa27\ndangling commit 925850b1e58b665bd5df508eb7cb99eedae8b472\ndangling commit a138760e4b7c324fd54e52998ab19ed4c4106064\ndangling blob de788db974ca67606102f301cbc9926a55e1d9a2\ndangling blob 0d7943f697e316b9d97ff89b0efc341425205426\ndangling commit 0e999989958b7b7a9e5718500bc0d2122e5155ac\ndangling blob 2d59c05f686f88684c65359e2af46b0a2e2c1385\ndangling blob 96591f7dc1e9f6d1b540884c2201da25b4435611\ndangling blob b239ff3b282c9d45d5e901835f217dc28b949b32\ndangling blob df7968cdc5d56584641f611f6f907727048d72cf\ndangling blob 1f5a1377e8f920e9392696f1187886b85a65c794\ndangling blob 49fbe34371c0ddd391f35ec05c5e6b9166016fa1\ndangling blob 599bdfe5070788fc301d3002ee3973383d0b6cf9\ndangling commit 5a3b29c6cf9a62252e607d2a367402549b981b67\ndangling blob 1edc5a3c2de4a883e0b959a663727bff691707af\ndangling blob 81fc0a7f742d6c9c629d22fc3a8eccfc631f2165\ndangling commit 3e7ddd2f7b25d6422a6baae129cc4c2a1be09728\ndangling blob 90dd4cf5ae9c6d9b8eefff04099ec76093622738\ndangling blob 9b3ddb9a8e5ac2adbf0f2c3b40e9c93f95b3770d\ndangling commit e67d527c84eeb095ab8a627cc0d369e49708af1b\ndangling blob 061e173ee667f82b952f57998fc7666420cbeca5\ndangling commit 3bbef5a498d6fbfe34a5f06828da1f9b1f26990d\ndangling commit 6e7e6d49490c88a3c974f80baa94a505453b3b87\ndangling blob 87be2bcf0238fc64671dfb4d3c56b5116f8e0939\ndangling commit 8fde9bf8b855191936f565f8ce1207da4ff7f70f\ndangling blob 967e88babd993b76f9e03916beb28c2bea7accbd\ndangling blob c6be8987d0adeac36a53691076950a68440e6b1e\ndangling commit d59ed0675627b36d7ad836b810a3ede13cbdee17\ndangling blob 48dff406c16f2aa182e0e22f87cd7a4bef600072\ndangling commit 4adf7f23bba31cbb7b0628367c51aba0e68359c5\ndangling blob 81ff52ca8932c6f5b64737b28e07a18af0056f38\n"},{"id":"262563","messageId":"20150601085226.GA20537@peff.net","threadId":"39475","inReplyTo":"556C1A95.9010704@atlas-elektronik.com","subject":"Re: git gc gives \"error: Could not read...\"","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-06-01T08:52:26Z","receivedAt":"2015-06-01T08:52:26Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jun 01, 2015 at 10:40:53AM +0200, Stefan Näwe wrote:\n\n> Turns out to be a tree:\n> \n> tree 7713c3b1e9ea2dd9126244697389e4000bb39d85\n> parent d7acfc22fbc0fba467d82f41c90aab7d61f8d751\n> author Stefan Naewe <stefan.naewe@atlas-elektronik.com> 1429536806 +0200\n> committer Stefan Naewe <stefan.naewe@atlas-elektronik.com> 1429536806 +0200\n\nYeah, I bungled the grep earlier. That message can come from a missing\ntag, tree, or commit object. But I think the root cause is the same.\n\n> Not exactly. My msysgit is merge-rebase'd (or rebase-merge'd...) onto v2.2.0...\n> I'll try older versions (pre v2.2.0) on linux.\n\nOK, that makes more sense then.\n\n> I also cloned from local filesystem (widnows drive) to a samba share.\n\nAnd that, too.\n\nI've managed to create a small test case that replicates the problem:\n\ndiff --git a/t/t6501-freshen-objects.sh b/t/t6501-freshen-objects.sh\nindex 157f3f9..015b0da 100755\n--- a/t/t6501-freshen-objects.sh\n+++ b/t/t6501-freshen-objects.sh\n@@ -129,4 +129,19 @@ for repack in '' true; do\n \t'\n done\n \n+test_expect_failure 'do not complain about existing broken links' '\n+\tcat >broken-commit <<-\\EOF &&\n+\ttree 0000000000000000000000000000000000000001\n+\tparent 0000000000000000000000000000000000000002\n+\tauthor whatever <whatever@example.com> 1234 -0000\n+\tcommitter whatever <whatever@example.com> 1234 -0000\n+\n+\tsome message\n+\tEOF\n+\tcommit=$(git hash-object -t commit -w broken-commit) &&\n+\tgit gc 2>stderr &&\n+\tverbose git cat-file -e $commit &&\n+\ttest_must_be_empty stderr\n+'\n+\n test_done\n\nwhich produces:\n\n  'stderr' is not empty, it contains:\n  error: Could not read 0000000000000000000000000000000000000002\n  error: Could not read 0000000000000000000000000000000000000001\n  error: Could not read 0000000000000000000000000000000000000002\n  error: Could not read 0000000000000000000000000000000000000001\n\nUnfortunately the fix is a little bit invasive. I'll send something out\nin a few minutes.\n\n-Peff\n"},{"id":"262564","messageId":"556C2273.4030405@atlas-elektronik.com","threadId":"39475","inReplyTo":"20150601085226.GA20537@peff.net","subject":"Re: git gc gives \"error: Could not read...\"","fromName":"Stefan Näwe","fromEmail":"stefan.naewe@atlas-elektronik.com","sentAt":"2015-06-01T09:14:27Z","receivedAt":"2015-06-01T09:14:27Z","isPatch":false,"sender":{"key":"stefan.naewe@gmail.com","avatar":"https://avatars.githubusercontent.com/u/4468?v=4"},"body":"Am 01.06.2015 um 10:52 schrieb Jeff King:\n> On Mon, Jun 01, 2015 at 10:40:53AM +0200, Stefan Näwe wrote:\n> \n>> Turns out to be a tree:\n>>\n>> tree 7713c3b1e9ea2dd9126244697389e4000bb39d85\n>> parent d7acfc22fbc0fba467d82f41c90aab7d61f8d751\n>> author Stefan Naewe <stefan.naewe@atlas-elektronik.com> 1429536806 +0200\n>> committer Stefan Naewe <stefan.naewe@atlas-elektronik.com> 1429536806 +0200\n> \n> Yeah, I bungled the grep earlier. That message can come from a missing\n> tag, tree, or commit object. But I think the root cause is the same.\n\nMaybe this one:\n\n   d3038d (prune: keep objects reachable from recent objects)\n\n??\nThat's what 'git bisect' told me.\n\n>> Not exactly. My msysgit is merge-rebase'd (or rebase-merge'd...) onto v2.2.0...\n>> I'll try older versions (pre v2.2.0) on linux.\n> \n> OK, that makes more sense then.\n> \n>> I also cloned from local filesystem (widnows drive) to a samba share.\n> \n> And that, too.\n> \n> I've managed to create a small test case that replicates the problem:\n> \n> diff --git a/t/t6501-freshen-objects.sh b/t/t6501-freshen-objects.sh\n> index 157f3f9..015b0da 100755\n> --- a/t/t6501-freshen-objects.sh\n> +++ b/t/t6501-freshen-objects.sh\n> @@ -129,4 +129,19 @@ for repack in '' true; do\n>  \t'\n>  done\n>  \n> +test_expect_failure 'do not complain about existing broken links' '\n> +\tcat >broken-commit <<-\\EOF &&\n> +\ttree 0000000000000000000000000000000000000001\n> +\tparent 0000000000000000000000000000000000000002\n> +\tauthor whatever <whatever@example.com> 1234 -0000\n> +\tcommitter whatever <whatever@example.com> 1234 -0000\n> +\n> +\tsome message\n> +\tEOF\n> +\tcommit=$(git hash-object -t commit -w broken-commit) &&\n> +\tgit gc 2>stderr &&\n> +\tverbose git cat-file -e $commit &&\n> +\ttest_must_be_empty stderr\n> +'\n> +\n>  test_done\n> \n> which produces:\n> \n>   'stderr' is not empty, it contains:\n>   error: Could not read 0000000000000000000000000000000000000002\n>   error: Could not read 0000000000000000000000000000000000000001\n>   error: Could not read 0000000000000000000000000000000000000002\n>   error: Could not read 0000000000000000000000000000000000000001\n> \n> Unfortunately the fix is a little bit invasive. I'll send something out\n> in a few minutes.\n\nIt would be really helpful if you sent the patch as an attachment.\nI know that's not the normal wokflow but our mail server garbles every\nmessage so that I can't (or don't know how to...) use 'git am' to test\nthe patch, which I'm willing to do!\n\nThanks,\n  Stefan\n-- \n----------------------------------------------------------------\n/dev/random says: The cost of feathers has risen... Now even DOWN is up!\npython -c \"print '73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')\" \nGPG Key fingerprint = 2DF5 E01B 09C3 7501 BCA9  9666 829B 49C5 9221 27AF\n"},{"id":"262565","messageId":"20150601095410.GA16976@peff.net","threadId":"39475","inReplyTo":"20150601085226.GA20537@peff.net","subject":"[RFC/PATCH 0/3] silence missing-link warnings in some cases","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-06-01T09:54:10Z","receivedAt":"2015-06-01T09:54:10Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"Stefan noticed that running \"git gc\" with a recent version of git causes\nsome useless complaints about missing objects.\n\nThe reason is that since git d3038d2 (prune: keep objects reachable from\nrecent objects, 2014-10-15), we will traverse objects that are not\nreachable but have recent mtimes (within the 2-week prune expiration\nwindow). Because they are not reachable, we may not actually have all of\ntheir ancestors; we use the revs->ignore_missing_links option to avoid\nmaking this a fatal error. But we still print an error message. This\nseries suppresses those messages.\n\nThe first two patches below implement that. The third one gives the same\ntreatment to UNINTERESTING parents, which we implicitly ignore when they\nare missing. I have slightly mixed feelings on this, just because it\ncould be a clue that there is repo corruption. E.g., if you do:\n\n  git log foo..bar\n\nand we find that \"foo^\" is missing, it is the only error message you\nget. OTOH, I think the reason we ignore errors with UNINTERESTING\nparents is that it does not necessarily mean corruption. E.g., while\nserving a fetch, if the client claims to have \"x\", we check only\n\"has_sha1_file(x)\" before putting the object on the UNINTERESTING side\nof our traversal. It might not be reachable at all, but rather just part\nof an incomplete segment of unreachable history. Of course, with modern\ngit (post-d3038d2), we try to avoid getting that situation in the first\nplace, which means that it _is_ an exceptional situation, and we should\ncontinue to at least print the error message.\n\nNote that post-d3038d2, it is also exceptional to see this in the\nignore_missing_link cases, too. The reason Stefan is seeing it is\nprobably that the repo was pruned in the past 2 weeks by an older\nversion of git (so it removed an older \"x^\", but kept \"x\"; whereas\nmodern git would keep both). So yet another possibility is to scrap this\nwhole series. Within 2 weeks the problem will magically go away on its\nown, or sooner if the user runs \"git prune\".\n\n  [1/3]: add quieter versions of parse_{tree,commit}\n  [2/3]: silence broken link warnings with revs->ignore_missing_links\n  [3/3]: suppress errors on missing UNINTERESTING links\n\n-Peff\n"},{"id":"262566","messageId":"20150601095625.GA31389@peff.net","threadId":"39475","inReplyTo":"20150601095410.GA16976@peff.net","subject":"[PATCH 1/3] add quieter versions of parse_{tree,commit}","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-06-01T09:56:26Z","receivedAt":"2015-06-01T09:56:26Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"When we call parse_commit, it will complain to stderr if the\nobject does not exist or cannot be read. This means that we\nmay produce useless error messages if this situation is\nexpected (e.g., because the object is marked UNINTERESTING,\nor because revs->ignore_missing_links is set).\n\nWe can fix this by adding a new \"parse_X_gently\" form that\ntakes a flag to suppress the messages. The existing\n\"parse_X\" form is already gentle in the sense that it\nreturns an error rather than dying, and we could in theory\njust add a \"quiet\" flag to it (with existing callers passing\n\"0\"). But doing it this way means we do not have to disturb\nexisting callers.\n\nNote also that the new flag is \"quiet_on_missing\", and not\njust \"quiet\". We could add a flag to suppress _all_ errors,\nbut besides being a more invasive change (we would have to\npass the flag down to sub-functions, too), there is a good\nreason not to: we would never want to use it. Missing a\nlinked object is expected in some circumstances, but it is\nnever expected to have a malformed commit, or to get a tree\nwhen we wanted a commit.  We should always complain about\nthese corruptions.\n\nSigned-off-by: Jeff King <peff@peff.net>\n---\n commit.c | 5 +++--\n commit.h | 6 +++++-\n tree.c   | 5 +++--\n tree.h   | 6 +++++-\n 4 files changed, 16 insertions(+), 6 deletions(-)\n\ndiff --git a/commit.c b/commit.c\nindex 2d9de80..6e2103c 100644\n--- a/commit.c\n+++ b/commit.c\n@@ -357,7 +357,7 @@ int parse_commit_buffer(struct commit *item, const void *buffer, unsigned long s\n \treturn 0;\n }\n \n-int parse_commit(struct commit *item)\n+int parse_commit_gently(struct commit *item, int quiet_on_missing)\n {\n \tenum object_type type;\n \tvoid *buffer;\n@@ -370,7 +370,8 @@ int parse_commit(struct commit *item)\n \t\treturn 0;\n \tbuffer = read_sha1_file(item->object.sha1, &type, &size);\n \tif (!buffer)\n-\t\treturn error(\"Could not read %s\",\n+\t\treturn quiet_on_missing ? -1 :\n+\t\t\terror(\"Could not read %s\",\n \t\t\t     sha1_to_hex(item->object.sha1));\n \tif (type != OBJ_COMMIT) {\n \t\tfree(buffer);\ndiff --git a/commit.h b/commit.h\nindex ed3a1d5..9a1fa96 100644\n--- a/commit.h\n+++ b/commit.h\n@@ -59,7 +59,11 @@ struct commit *lookup_commit_reference_by_name(const char *name);\n struct commit *lookup_commit_or_die(const unsigned char *sha1, const char *ref_name);\n \n int parse_commit_buffer(struct commit *item, const void *buffer, unsigned long size);\n-int parse_commit(struct commit *item);\n+int parse_commit_gently(struct commit *item, int quiet_on_missing);\n+static inline int parse_commit(struct commit *item)\n+{\n+\treturn parse_commit_gently(item, 0);\n+}\n void parse_commit_or_die(struct commit *item);\n \n /*\ndiff --git a/tree.c b/tree.c\nindex 58ebfce..413a5b1 100644\n--- a/tree.c\n+++ b/tree.c\n@@ -204,7 +204,7 @@ int parse_tree_buffer(struct tree *item, void *buffer, unsigned long size)\n \treturn 0;\n }\n \n-int parse_tree(struct tree *item)\n+int parse_tree_gently(struct tree *item, int quiet_on_missing)\n {\n \t enum object_type type;\n \t void *buffer;\n@@ -214,7 +214,8 @@ int parse_tree(struct tree *item)\n \t\treturn 0;\n \tbuffer = read_sha1_file(item->object.sha1, &type, &size);\n \tif (!buffer)\n-\t\treturn error(\"Could not read %s\",\n+\t\treturn quiet_on_missing ? -1 :\n+\t\t\terror(\"Could not read %s\",\n \t\t\t     sha1_to_hex(item->object.sha1));\n \tif (type != OBJ_TREE) {\n \t\tfree(buffer);\ndiff --git a/tree.h b/tree.h\nindex d24125f..d24786c 100644\n--- a/tree.h\n+++ b/tree.h\n@@ -16,7 +16,11 @@ struct tree *lookup_tree(const unsigned char *sha1);\n \n int parse_tree_buffer(struct tree *item, void *buffer, unsigned long size);\n \n-int parse_tree(struct tree *tree);\n+int parse_tree_gently(struct tree *tree, int quiet_on_missing);\n+static inline int parse_tree(struct tree *tree)\n+{\n+\treturn parse_tree_gently(tree, 0);\n+}\n void free_tree_buffer(struct tree *tree);\n \n /* Parses and returns the tree in the given ent, chasing tags and commits. */\n-- \n2.4.2.690.g2a79674\n"},{"id":"262568","messageId":"20150601095636.GB31389@peff.net","threadId":"39475","inReplyTo":"20150601095410.GA16976@peff.net","subject":"[PATCH 2/3] silence broken link warnings with revs->ignore_missing_links","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-06-01T09:56:37Z","receivedAt":"2015-06-01T09:56:37Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"We set revs->ignore_missing_links to instruct the\nrevision-walking machinery that we know the history graph\nmay be incomplete. For example, we use it when walking\nunreachable but recent objects; we want to add what we can,\nbut it's OK if the history is incomplete.\n\nHowever, we still print error messages for the missing\nobjects, which can be confusing. This is not an error, but\njust a normal situation when transitioning from a repository\nlast pruned by an older git (which can leave broken segments\nof history) to a more recent one (where we try to preserve\nwhole reachable segments).\n\nSigned-off-by: Jeff King <peff@peff.net>\n---\n list-objects.c             |  2 +-\n revision.c                 |  2 +-\n t/t6501-freshen-objects.sh | 15 +++++++++++++++\n 3 files changed, 17 insertions(+), 2 deletions(-)\n\ndiff --git a/list-objects.c b/list-objects.c\nindex 2a139b6..41736d2 100644\n--- a/list-objects.c\n+++ b/list-objects.c\n@@ -81,7 +81,7 @@ static void process_tree(struct rev_info *revs,\n \t\tdie(\"bad tree object\");\n \tif (obj->flags & (UNINTERESTING | SEEN))\n \t\treturn;\n-\tif (parse_tree(tree) < 0) {\n+\tif (parse_tree_gently(tree, revs->ignore_missing_links) < 0) {\n \t\tif (revs->ignore_missing_links)\n \t\t\treturn;\n \t\tdie(\"bad tree object %s\", sha1_to_hex(obj->sha1));\ndiff --git a/revision.c b/revision.c\nindex 7ddbaa0..29e5143 100644\n--- a/revision.c\n+++ b/revision.c\n@@ -844,7 +844,7 @@ static int add_parents_to_list(struct rev_info *revs, struct commit *commit,\n \tfor (parent = commit->parents; parent; parent = parent->next) {\n \t\tstruct commit *p = parent->item;\n \n-\t\tif (parse_commit(p) < 0)\n+\t\tif (parse_commit_gently(p, revs->ignore_missing_links) < 0)\n \t\t\treturn -1;\n \t\tif (revs->show_source && !p->util)\n \t\t\tp->util = commit->util;\ndiff --git a/t/t6501-freshen-objects.sh b/t/t6501-freshen-objects.sh\nindex 157f3f9..2adf825 100755\n--- a/t/t6501-freshen-objects.sh\n+++ b/t/t6501-freshen-objects.sh\n@@ -129,4 +129,19 @@ for repack in '' true; do\n \t'\n done\n \n+test_expect_success 'do not complain about existing broken links' '\n+\tcat >broken-commit <<-\\EOF &&\n+\ttree 0000000000000000000000000000000000000001\n+\tparent 0000000000000000000000000000000000000002\n+\tauthor whatever <whatever@example.com> 1234 -0000\n+\tcommitter whatever <whatever@example.com> 1234 -0000\n+\n+\tsome message\n+\tEOF\n+\tcommit=$(git hash-object -t commit -w broken-commit) &&\n+\tgit gc 2>stderr &&\n+\tverbose git cat-file -e $commit &&\n+\ttest_must_be_empty stderr\n+'\n+\n test_done\n-- \n2.4.2.690.g2a79674\n"},{"id":"262567","messageId":"20150601095640.GC31389@peff.net","threadId":"39475","inReplyTo":"20150601095410.GA16976@peff.net","subject":"[PATCH 3/3] suppress errors on missing UNINTERESTING links","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-06-01T09:56:40Z","receivedAt":"2015-06-01T09:56:40Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"When we are traversing commit parents along the\nUNINTERESTING side of a revision walk, we do not care if\nthe parent turns out to be missing. That lets us limit\ntraversals using unreachable and possibly incomplete\nsections of history. However, we do still print error\nmessages about the missing commits; this patch suppresses\nthe error, as well.\n\nSigned-off-by: Jeff King <peff@peff.net>\n---\n revision.c | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/revision.c b/revision.c\nindex 29e5143..0b322b4 100644\n--- a/revision.c\n+++ b/revision.c\n@@ -817,7 +817,7 @@ static int add_parents_to_list(struct rev_info *revs, struct commit *commit,\n \t\t\tparent = parent->next;\n \t\t\tif (p)\n \t\t\t\tp->object.flags |= UNINTERESTING;\n-\t\t\tif (parse_commit(p) < 0)\n+\t\t\tif (parse_commit_gently(p, 1) < 0)\n \t\t\t\tcontinue;\n \t\t\tif (p->parents)\n \t\t\t\tmark_parents_uninteresting(p);\n-- \n2.4.2.690.g2a79674\n"},{"id":"262572","messageId":"20150601095850.GD31389@peff.net","threadId":"39475","inReplyTo":"556C2273.4030405@atlas-elektronik.com","subject":"Re: git gc gives \"error: Could not read...\"","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-06-01T09:58:51Z","receivedAt":"2015-06-01T09:58:51Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jun 01, 2015 at 11:14:27AM +0200, Stefan Näwe wrote:\n\n> Maybe this one:\n> \n>    d3038d (prune: keep objects reachable from recent objects)\n\nYes, exactly.\n\n> It would be really helpful if you sent the patch as an attachment.\n> I know that's not the normal wokflow but our mail server garbles every\n> message so that I can't (or don't know how to...) use 'git am' to test\n> the patch, which I'm willing to do!\n\nIt ended up as a patch series. However, you can fetch it from:\n\n  git://github.com/peff/git.git jk/silence-unreachable-broken-links\n\nwhich is perhaps even easier.\n\n-Peff\n"},{"id":"262573","messageId":"556C2F1B.1060508@atlas-elektronik.com","threadId":"39475","inReplyTo":"20150601095850.GD31389@peff.net","subject":"Re: git gc gives \"error: Could not read...\"","fromName":"Stefan Näwe","fromEmail":"stefan.naewe@atlas-elektronik.com","sentAt":"2015-06-01T10:08:27Z","receivedAt":"2015-06-01T10:08:27Z","isPatch":false,"sender":{"key":"stefan.naewe@gmail.com","avatar":"https://avatars.githubusercontent.com/u/4468?v=4"},"body":"Am 01.06.2015 um 11:58 schrieb Jeff King:\n> On Mon, Jun 01, 2015 at 11:14:27AM +0200, Stefan Näwe wrote:\n> \n>> Maybe this one:\n>>\n>>    d3038d (prune: keep objects reachable from recent objects)\n> \n> Yes, exactly.\n> \n>> It would be really helpful if you sent the patch as an attachment.\n>> I know that's not the normal wokflow but our mail server garbles every\n>> message so that I can't (or don't know how to...) use 'git am' to test\n>> the patch, which I'm willing to do!\n> \n> It ended up as a patch series. However, you can fetch it from:\n> \n>   git://github.com/peff/git.git jk/silence-unreachable-broken-links\n> \n> which is perhaps even easier.\n\nNot really in my situation...(but that's another story)\n\nI managed to create patch files by simply copy-and-pasting the message\ntext (and the From:, Date:, and Subject: fields from 'View message source' in Thunderbird...)\nwhich I could then 'git am' ;-)\n\nThe patches applied (and compiled) cleanly on v2.4.2 and 'git gc'\nstopped giving me the error message.\n\nSo (FWIW):\n\nTested-by: Stefan Naewe <stefan.naewe@gmail.com>\n\nAnything else I could test ?\n\nThanks,\n  Stefan\n-- \n----------------------------------------------------------------\n/dev/random says: Windows N'T: as in Wouldn't, Couldn't, and Didn't.\npython -c \"print '73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')\" \nGPG Key fingerprint = 2DF5 E01B 09C3 7501 BCA9  9666 829B 49C5 9221 27AF\n"},{"id":"262575","messageId":"20150601102249.GB31792@peff.net","threadId":"39475","inReplyTo":"556C2F1B.1060508@atlas-elektronik.com","subject":"Re: git gc gives \"error: Could not read...\"","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-06-01T10:22:50Z","receivedAt":"2015-06-01T10:22:50Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jun 01, 2015 at 12:08:27PM +0200, Stefan Näwe wrote:\n\n> > It ended up as a patch series. However, you can fetch it from:\n> > \n> >   git://github.com/peff/git.git jk/silence-unreachable-broken-links\n> > \n> > which is perhaps even easier.\n> \n> Not really in my situation...(but that's another story)\n\nOh, sorry. :)\n\n> So (FWIW):\n> \n> Tested-by: Stefan Naewe <stefan.naewe@gmail.com>\n> \n> Anything else I could test ?\n\nThanks for confirming (though I was pretty sure it was the problem when\nyou bisected to the same commit I suspected). My only open questions are\nthe concerns I raised in the cover letter, but I don't think there is\nanything else for you to test there.\n\n-Peff\n"},{"id":"262602","messageId":"xmqqmw0j8o9i.fsf@gitster.dls.corp.google.com","threadId":"39475","inReplyTo":"20150601095410.GA16976@peff.net","subject":"Re: [RFC/PATCH 0/3] silence missing-link warnings in some cases","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-06-01T15:03:05Z","receivedAt":"2015-06-01T15:03:05Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> Stefan noticed that running \"git gc\" with a recent version of git causes\n> some useless complaints about missing objects.\n>\n> The reason is that since git d3038d2 (prune: keep objects reachable from\n> recent objects, 2014-10-15), we will traverse objects that are not\n> reachable but have recent mtimes (within the 2-week prune expiration\n> window). Because they are not reachable, we may not actually have all of\n> their ancestors; we use the revs->ignore_missing_links option to avoid\n> making this a fatal error. But we still print an error message. This\n> series suppresses those messages.\n\nNice finding.  One of us should have thought of this kind of fallout\nwhen we discussed that change, but we apparently failed.\n\nThe fixes make sense to me (I haven't carefully read the\nimplementation, but design/approach explained in the proposed log\nmessages are very sound), and I think 3/3 is a good thing to do,\ntoo, in the new world order after d3038d2.\n\nThanks, both.\n"},{"id":"262607","messageId":"20150601154103.GA14538@peff.net","threadId":"39475","inReplyTo":"xmqqmw0j8o9i.fsf@gitster.dls.corp.google.com","subject":"Re: [RFC/PATCH 0/3] silence missing-link warnings in some cases","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-06-01T15:41:03Z","receivedAt":"2015-06-01T15:41:03Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jun 01, 2015 at 08:03:05AM -0700, Junio C Hamano wrote:\n\n> > The reason is that since git d3038d2 (prune: keep objects reachable from\n> > recent objects, 2014-10-15), we will traverse objects that are not\n> > reachable but have recent mtimes (within the 2-week prune expiration\n> > window). Because they are not reachable, we may not actually have all of\n> > their ancestors; we use the revs->ignore_missing_links option to avoid\n> > making this a fatal error. But we still print an error message. This\n> > series suppresses those messages.\n> \n> Nice finding.  One of us should have thought of this kind of fallout\n> when we discussed that change, but we apparently failed.\n\nI think the real culprit is that this should have been added along with\nignore_missing_links in the first place. That came along with the bitmap\ncode, but I was too busy focusing on the hard problems there to notice.\n:)\n\n> The fixes make sense to me (I haven't carefully read the\n> implementation, but design/approach explained in the proposed log\n> messages are very sound), and I think 3/3 is a good thing to do,\n> too, in the new world order after d3038d2.\n\nI think it's rather the opposite. In a post-d3038d2 world, a missing\nobject is _more_ likely to be a real corruption, and we would probably\nprefer to complain about it. I am on the fence though.\n\n-Peff\n"},{"id":"262614","messageId":"xmqq7frn8l2r.fsf@gitster.dls.corp.google.com","threadId":"39475","inReplyTo":"20150601154103.GA14538@peff.net","subject":"Re: [RFC/PATCH 0/3] silence missing-link warnings in some cases","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-06-01T16:11:56Z","receivedAt":"2015-06-01T16:11:56Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n>> The fixes make sense to me (I haven't carefully read the\n>> implementation, but design/approach explained in the proposed log\n>> messages are very sound), and I think 3/3 is a good thing to do,\n>> too, in the new world order after d3038d2.\n>\n> I think it's rather the opposite. In a post-d3038d2 world, a missing\n> object is _more_ likely to be a real corruption, and we would probably\n> prefer to complain about it. I am on the fence though.\n\nSorry, but I wasn't talking about that far in the future.\n\nIn the immediate future that necessitates patches 1 and 2, a warning\non such a missing object from the codepath in 3 would be equally\nannoying noise, no?  And a purely post-d3038d2 world, all of these\nwarnings may be pointing at a real corruption, as you referred to as\n\"yet another possibility\".\n\nAs you said, these should have been part of ignore-missing-links, so\nI'd say we should treat the codepaths that special case the callers\nthat pass that option the same way.\n\nHaving said all that, I do not think it is healthy to assume that\npre-d3038d2 prune is the only thing that may leave an incomplete and\nunreachable island of objects in the repository (two easy ways to do\nso are to interrupt unpack-objects or the commit walker dumb fetch).\nSo from that point of view, these three patches are reasonable\nthings to keep even in the longer term (in other words, I do not\nthink \"yet another possibility\" of waiting for the older versions of\ngc/prune to die out is a viable solution to the issue Stefan Näwe\nnoticed).\n\nThanks.\n"}]}