{"thread":{"id":"50688","subject":"Improve support for 'git config gc.reflogExpire never'","startedAt":"2019-03-08T08:35:01Z","lastAt":"2019-03-19T09:30:22Z","messageCount":3,"participants":["Mikko Rantalainen","Jeff King","Ævar Arnfjörð Bjarmason"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"370942","messageId":"39a0796a-7220-1e81-e7fe-3bf7329ed7de@peda.net","threadId":"50688","inReplyTo":null,"subject":"Improve support for 'git config gc.reflogExpire never'","fromName":"Mikko Rantalainen","fromEmail":"mikko.rantalainen@peda.net","sentAt":"2019-03-08T08:27:11Z","receivedAt":"2019-03-08T08:35:01Z","isPatch":false,"sender":{"key":"mikko.rantalainen@peda.net","avatar":"https://gravatar.com/avatar/e2d770957fa98e434c238272a8ee24c02ab5766ad140c18b9591045c0a49be58?d=mp&s=160"},"body":"If I configure bare repo with\n\ngit config gc.pruneExpire never\ngit config gc.reflogExpire never\n\nthen git will never garbage collect any commit ever stored in the repo.\nThis is what I want.\n\nHowever, all commits referenced only via reflog are kept as loose\nobjects and will not be included in packs. In long run this will cause\n\nwarning: There are too many unreachable loose objects; run 'git prune'\nto remove them.\n\nand the performance of the repository will slowly decrease.\n\n\nIf I have understood correctly, git should notice that reflog will keep\nreferenced commits forever and include all those commits in packs\ninstead of keeping those as loose forever.\n\nA more generic behavior might be to always compress all loose commits in\n(one?) special pack so the performance would stay good even if\ngc.reflogExpire is very long instead of \"never\".\n\n\nDiscussion about this case:\nhttps://stackoverflow.com/questions/28092485/how-to-prevent-garbage-collection-in-git\nhttps://stackoverflow.com/questions/55043693/is-it-possible-to-get-git-gc-to-pack-reflog-objects\n\n-- \nMikko\n"},{"id":"371882","messageId":"20190319064711.GD31801@sigill.intra.peff.net","threadId":"50688","inReplyTo":"39a0796a-7220-1e81-e7fe-3bf7329ed7de@peda.net","subject":"Re: Improve support for 'git config gc.reflogExpire never'","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-03-19T06:47:12Z","receivedAt":"2019-03-19T06:47:15Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Mar 08, 2019 at 10:27:11AM +0200, Mikko Rantalainen wrote:\n\n> If I configure bare repo with\n> \n> git config gc.pruneExpire never\n> git config gc.reflogExpire never\n> \n> then git will never garbage collect any commit ever stored in the repo.\n> This is what I want.\n> \n> However, all commits referenced only via reflog are kept as loose\n> objects and will not be included in packs. In long run this will cause\n> \n> warning: There are too many unreachable loose objects; run 'git prune'\n> to remove them.\n> \n> and the performance of the repository will slowly decrease.\n\nThat's not what's supposed to happen. A normal git-gc (or directly\nrunning the \"git repack\" it spawns) should consider objects in reflogs\nreachable, and pack them as it would an object reachable from a ref.\nThis has been the case since 63049292e0 (Teach git-repack to preserve\nobjects referred to by reflog entries., 2006-12-18).\n\nJust to double check: are you sure you have reflogs? They're not enabled\nby default in bare repos.\n\nAnother thing that may surprise you is that deleting a branch will\ndelete its reflog (and then the objects are unreachable, and may be\nexploded loose).\n\n> If I have understood correctly, git should notice that reflog will keep\n> referenced commits forever and include all those commits in packs\n> instead of keeping those as loose forever.\n\nYes, that's what's supposed to happen. If you have a recipe for\nreproducing a case where it doesn't, I'd be curious to see it.\n\n> A more generic behavior might be to always compress all loose commits in\n> (one?) special pack so the performance would stay good even if\n> gc.reflogExpire is very long instead of \"never\".\n\nYou can do \"git repack -adk\", which will keep all packed objects packed,\nand will suck up loose objects into the pack (and delete their loose\ncounterparts). I don't think there's a convenient way to convince git-gc\nto do this when it runs \"git repack\", though. I think it would be a\nreasonable feature for it to have.\n\n-Peff\n"},{"id":"371895","messageId":"87a7hrdxee.fsf@evledraar.gmail.com","threadId":"50688","inReplyTo":"39a0796a-7220-1e81-e7fe-3bf7329ed7de@peda.net","subject":"Re: Improve support for 'git config gc.reflogExpire never'","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2019-03-19T09:30:17Z","receivedAt":"2019-03-19T09:30:22Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Fri, Mar 08 2019, Mikko Rantalainen wrote:\n\n> If I configure bare repo with\n>\n> git config gc.pruneExpire never\n> git config gc.reflogExpire never\n>\n> then git will never garbage collect any commit ever stored in the repo.\n> This is what I want.\n>\n> However, all commits referenced only via reflog are kept as loose\n> objects and will not be included in packs. In long run this will cause\n>\n> warning: There are too many unreachable loose objects; run 'git prune'\n> to remove them.\n>\n> and the performance of the repository will slowly decrease.\n>\n>\n> If I have understood correctly, git should notice that reflog will keep\n> referenced commits forever and include all those commits in packs\n> instead of keeping those as loose forever.\n>\n> A more generic behavior might be to always compress all loose commits in\n> (one?) special pack so the performance would stay good even if\n> gc.reflogExpire is very long instead of \"never\".\n>\n>\n> Discussion about this case:\n> https://stackoverflow.com/questions/28092485/how-to-prevent-garbage-collection-in-git\n> https://stackoverflow.com/questions/55043693/is-it-possible-to-get-git-gc-to-pack-reflog-objects\n\nJust to add to Jeff's E-Mail, the case he's describing is something I\nwrote a stand-alone test case for here:\nhttps://public-inbox.org/git/87fu6bmr0j.fsf@evledraar.gmail.com/\n\nTry to run it, it's probably the same behavior you're seeing, and it has\nnothing per-se to do with reflogs.\n"}]}