{"thread":{"id":"13229","subject":"git-gc doesn't clean up leftover objects after git-filter-branch unless you clone first","startedAt":"2008-04-23T15:41:42Z","lastAt":"2008-04-30T01:01:52Z","messageCount":12,"participants":["Avery Pennarun","Junio C Hamano","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"75069","messageId":"32541b130804230841h32c07f3arc94cccfaf0b156a3@mail.gmail.com","threadId":"13229","inReplyTo":null,"subject":"git-gc doesn't clean up leftover objects after git-filter-branch unless you clone first","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2008-04-23T15:41:42Z","receivedAt":"2008-04-23T15:41:42Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On 4/23/08, Johannes Sixt wrote:\n> Peter Karlsson schrieb:\n> > [Not seeing any unreachable objects]\n>\n> > Jeff King:\n> >> Did you remove refs/original/ ?\n> >\n> > That, and cloned the repository to a new location after the conversion,\n> > and removing the references to \"origin\" there. It does seem that the\n> > objects are still there, but I can't see them with \"gitk --all\".\n>\n> Did you clone locally? Then you must use the file:// protocol, otherwise\n> everything is hard-linked from the origin.\n\nThis question has come up at least once a week since I subscribed to\nthe list. I can think of these solutions:\n\n- Add a note to the git-gc and/or git-repack man page about how hidden\nrefs can impact the cleanup.\n\n- Add an option to make git-clone *not* hardlink stuff; its different\nbehaviour for hardlinking vs. file:// seems to be very confusing.\n\n- Make git-gc give a warning when there are some objects that are only\nreferenced via the reflog or refs/original. (I suspect this would\ntrigger too often though.)\n\n- Give git-gc a \"really, I'm serious\" option that makes it ignore the\nreflog and refs/original.\n\nThoughts?\n\nAvery\n"},{"id":"75076","messageId":"7vve28sdys.fsf@gitster.siamese.dyndns.org","threadId":"13229","inReplyTo":"32541b130804230841h32c07f3arc94cccfaf0b156a3@mail.gmail.com","subject":"Re: git-gc doesn't clean up leftover objects after git-filter-branch unless you clone first","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-04-23T17:00:59Z","receivedAt":"2008-04-23T17:00:59Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Avery Pennarun\" writes:\n\n> This question has come up at least once a week since I subscribed to\n> the list. I can think of these solutions:\n>\n> - Add a note to the git-gc and/or git-repack man page about how hidden\n> refs can impact the cleanup.\n>\n> - Add an option to make git-clone *not* hardlink stuff; its different\n> behaviour for hardlinking vs. file:// seems to be very confusing.\n>\n> - Make git-gc give a warning when there are some objects that are only\n> referenced via the reflog or refs/original. (I suspect this would\n> trigger too often though.)\n>\n> - Give git-gc a \"really, I'm serious\" option that makes it ignore the\n> reflog and refs/original.\n\n- Teach people that leftover cruft is nothing to worry about.\n"},{"id":"75081","messageId":"32541b130804231136n73127cb9rea242981da28ac47@mail.gmail.com","threadId":"13229","inReplyTo":"7vve28sdys.fsf@gitster.siamese.dyndns.org","subject":"Re: git-gc doesn't clean up leftover objects after git-filter-branch unless you clone first","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2008-04-23T18:36:04Z","receivedAt":"2008-04-23T18:36:04Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On 4/23/08, Junio C Hamano wrote:\n> \"Avery Pennarun\" writes:\n>\n> > This question has come up at least once a week since I subscribed to\n> > the list. I can think of these solutions:\n> >\n> > - Add a note to the git-gc and/or git-repack man page about how hidden\n> > refs can impact the cleanup.\n> >\n> > - Add an option to make git-clone *not* hardlink stuff; its different\n> > behaviour for hardlinking vs. file:// seems to be very confusing.\n> >\n> > - Make git-gc give a warning when there are some objects that are only\n> > referenced via the reflog or refs/original. (I suspect this would\n> > trigger too often though.)\n> >\n> > - Give git-gc a \"really, I'm serious\" option that makes it ignore the\n> > reflog and refs/original.\n>\n> - Teach people that leftover cruft is nothing to worry about.\n\nI think any option that starts with \"teach people\" will not reduce FAQ\ntraffic to the list :) But maybe we could remind people of this\nsomewhere prominent. The git-filter-branch man page?\n\nThat said, I think I know why people are concerned about the cruft:\nit's for the same reason I was when I first tried git-filter-branch to\nget rid of some gigantic files after importing from svn, to cut the\nsize of a clone from >1GB to <100MB. It's impossible to see if I've\nsucceeded or not unless I make an actual clone, and even *then* I was\nmisled at first because making a local clone is clever and avoids\ndoing any work.\n\nAvery\n"},{"id":"75112","messageId":"20080423221316.GE30057@sigill.intra.peff.net","threadId":"13229","inReplyTo":"7vve28sdys.fsf@gitster.siamese.dyndns.org","subject":"Re: git-gc doesn't clean up leftover objects after git-filter-branch unless you clone first","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-04-23T22:13:16Z","receivedAt":"2008-04-23T22:13:16Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Apr 23, 2008 at 10:00:59AM -0700, Junio C Hamano wrote:\n\n> - Teach people that leftover cruft is nothing to worry about.\n\nBut it _is_ something to worry about in some particular situations. For\nrun-of-the-mill rebasing, sure, ignore it. But this question usually\ncomes up because the user did something like:\n\n 1. import from foreign SCM or other source\n 2. realize massive, history-wide mistake; git filter-branch\n to fix up the changes\n 3. wonder why git is using twice as much space as it needs to; with\n a repository in the hundreds or thousands of megs, this can get\n really annoying (either because of wasted space, or because some\n operations, like \"git repack -a\" actually do per-object work).\n\n-Peff\n"},{"id":"75126","messageId":"20080424012836.GA30812@sigill.intra.peff.net","threadId":"13229","inReplyTo":"20080423221316.GE30057@sigill.intra.peff.net","subject":"Re: git-gc doesn't clean up leftover objects after git-filter-branch unless you clone first","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-04-24T01:28:36Z","receivedAt":"2008-04-24T01:28:36Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Apr 23, 2008 at 06:13:16PM -0400, Jeff King wrote:\n\n> > - Teach people that leftover cruft is nothing to worry about.\n> \n> But it _is_ something to worry about in some particular situations. For\n> run-of-the-mill rebasing, sure, ignore it. But this question usually\n> comes up because the user did something like:\n\nOK, maybe I am wrong. Within a few hours of me posting this, somebody\nstarts a new thread with a toy example wondering why git-gc didn't clean\nup an --amended commit.\n\nI don't know the best way to teach people about this (short of using a\nbig stick, of course), but maybe something like this would help a\nlittle:\n\n-- >8 --\ndoc/git-gc: add a note about what is collected\n\nIt seems to be a FAQ that people try running git-gc, and\nthen get puzzled about why the size of their .git directory\ndidn't change. This note mentions the reasons why things\nmight unexpectedly get kept.\n\nSigned-off-by: Jeff King \n---\n Documentation/git-gc.txt | 15 +++++++++++++++\n 1 files changed, 15 insertions(+), 0 deletions(-)\n\ndiff --git a/Documentation/git-gc.txt b/Documentation/git-gc.txt\nindex d424a4e..9a4b62e 100644\n--- a/Documentation/git-gc.txt\n+++ b/Documentation/git-gc.txt\n@@ -104,6 +104,21 @@ The optional configuration variable 'gc.pruneExpire' controls how old\n the unreferenced loose objects have to be before they are pruned. The\n default is \"2 weeks ago\".\n \n+\n+Notes\n+-----\n+\n+git-gc tries very hard to be safe about the garbage it collects. In\n+particular, it will keep not only objects referenced by your current set\n+of branches and tags, but also objects referenced by the index, remote\n+tracking branches, refs saved by linkgit:git-filter-branch[1] in\n+refs/original/, or reflogs (which may references commits in branches\n+that were later amended or rewound).\n+\n+If you are expecting some objects to be collected and it isn't, check\n+all of those locations and decide whether it makes sense in your case to\n+remove those references.\n+\n See Also\n --------\n linkgit:git-prune[1]\n-- \n1.5.5.1.143.ge2bb9\n"},{"id":"75151","messageId":"32541b130804240843k471ecfeteb1008c44a56808b@mail.gmail.com","threadId":"13229","inReplyTo":"20080424012836.GA30812@sigill.intra.peff.net","subject":"Re: git-gc doesn't clean up leftover objects after git-filter-branch unless you clone first","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2008-04-24T15:43:55Z","receivedAt":"2008-04-24T15:43:55Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On 4/23/08, Jeff King wrote:\n> +\n> +Notes\n> +-----\n> +\n> +git-gc tries very hard to be safe about the garbage it collects. In\n> +particular, it will keep not only objects referenced by your current set\n> +of branches and tags, but also objects referenced by the index, remote\n> +tracking branches, refs saved by linkgit:git-filter-branch[1] in\n> +refs/original/, or reflogs (which may references commits in branches\n> +that were later amended or rewound).\n> +\n> +If you are expecting some objects to be collected and it isn't, check\n> +all of those locations and decide whether it makes sense in your case to\n> +remove those references.\n> +\n\nThis information would have helped me quite a bit when I first\nencountered this problem. It would be nice if it also showed up under\ngit-prune (since git-gc doesn't delete anything itself, if I\nunderstand correctly). Also a link to some information about reflogs\n(even just to \"see also\" git-reflog) would help, since I didn't hear\nabout reflogs at all until after I joined the mailing list.\n\nAvery\n"},{"id":"75153","messageId":"20080424161407.GA23737@sigill.intra.peff.net","threadId":"13229","inReplyTo":"32541b130804240843k471ecfeteb1008c44a56808b@mail.gmail.com","subject":"Re: git-gc doesn't clean up leftover objects after git-filter-branch unless you clone first","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-04-24T16:14:07Z","receivedAt":"2008-04-24T16:14:07Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Apr 24, 2008 at 11:43:55AM -0400, Avery Pennarun wrote:\n\n> > +If you are expecting some objects to be collected and it isn't, check\n> > +all of those locations and decide whether it makes sense in your case to\n> > +remove those references.\n> > +\n> \n> This information would have helped me quite a bit when I first\n> encountered this problem. It would be nice if it also showed up under\n> git-prune (since git-gc doesn't delete anything itself, if I\n\nHmm, maybe it would make sense to put that note in git-prune, with a\nnote in git-gc to look at the prune page.\n\n> understand correctly). Also a link to some information about reflogs\n> (even just to \"see also\" git-reflog) would help, since I didn't hear\n> about reflogs at all until after I joined the mailing list.\n\n$ grep -A6 See.Also Documentation/git-gc.txt\nSee Also\n--------\nlinkgit:git-prune[1]\nlinkgit:git-reflog[1]\nlinkgit:git-repack[1]\nlinkgit:git-rerere[1]\n\nBut if the note were moved to git-prune, it would be natural to mention\ngit-reflog there. What do you think?\n\n-Peff\n"},{"id":"75155","messageId":"32541b130804240959y3b05d4b5u67ac7a7c14bf187e@mail.gmail.com","threadId":"13229","inReplyTo":"20080424161407.GA23737@sigill.intra.peff.net","subject":"Re: git-gc doesn't clean up leftover objects after git-filter-branch unless you clone first","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2008-04-24T16:59:34Z","receivedAt":"2008-04-24T16:59:34Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On 4/24/08, Jeff King wrote:\n> Hmm, maybe it would make sense to put that note in git-prune, with a\n> note in git-gc to look at the prune page.\n\nPerhaps.\n\n> But if the note were moved to git-prune, it would be natural to mention\n> git-reflog there. What do you think?\n\nI gather there's a movement in recent git versions (sorry, I only\ntuned in recently) to encourage people to use git-gc instead of\ngit-prune in almost all cases. The reasons I ever looked at git-prune\nat all was that git-gc mentioned it in \"See Also\", and because\n\"git-prune\" sounded more obviously like what I wanted than \"git-gc\"\nwhen I looked at \"man git\".\n\nAdding git-gc *and* git-reflog as See Also entries in git-prune would\nmake sense to me.\n\nAvery\n"},{"id":"75573","messageId":"20080429204514.GA21029@sigill.intra.peff.net","threadId":"13229","inReplyTo":"32541b130804240959y3b05d4b5u67ac7a7c14bf187e@mail.gmail.com","subject":"[PATCH] Documentation: point git-prune users to git-gc","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-04-29T20:45:14Z","receivedAt":"2008-04-29T20:45:14Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Apr 24, 2008 at 12:59:34PM -0400, Avery Pennarun wrote:\n\n> I gather there's a movement in recent git versions (sorry, I only\n> tuned in recently) to encourage people to use git-gc instead of\n> git-prune in almost all cases. The reasons I ever looked at git-prune\n\nYes, I don't think there is any reason for most people to use git-prune\nat all, unless they are trying specifically to prune and don't want the\nother gc effects to happen.\n\nJunio, please correct me if I'm wrong there.\n\n> Adding git-gc *and* git-reflog as See Also entries in git-prune would\n> make sense to me.\n\nAgreed. Below is a patch that will hopefully clarify the situation.\n\n-- >8 --\nDocumentation: point git-prune users to git-gc\n\nMost users should be using git-gc instead of directly\ncalling prune. For those who really do want more information\non pruning, let's point them at git-fsck, which goes into\nslightly more detail on reachability.\n\nAnd since we're pointing users there, let's make sure\nreflogs are mentioned in git-fsck(1).\n\nSigned-off-by: Jeff King \n---\n Documentation/git-fsck.txt | 3 ++-\n Documentation/git-prune.txt | 20 ++++++++++++++++++++\n 2 files changed, 22 insertions(+), 1 deletions(-)\n\ndiff --git a/Documentation/git-fsck.txt b/Documentation/git-fsck.txt\nindex f16cb98..4cc26fb 100644\n--- a/Documentation/git-fsck.txt\n+++ b/Documentation/git-fsck.txt\n@@ -22,7 +22,8 @@ OPTIONS\n \tAn object to treat as the head of an unreachability trace.\n +\n If no objects are given, git-fsck defaults to using the\n-index file and all SHA1 references in .git/refs/* as heads.\n+index file, all SHA1 references in .git/refs/*, and all reflogs (unless\n+--no-reflogs is given) as heads.\n \n --unreachable::\n \tPrint out objects that exist but that aren't readable from any\ndiff --git a/Documentation/git-prune.txt b/Documentation/git-prune.txt\nindex f151cff..f92bb8c 100644\n--- a/Documentation/git-prune.txt\n+++ b/Documentation/git-prune.txt\n@@ -13,6 +13,9 @@ SYNOPSIS\n DESCRIPTION\n -----------\n \n+NOTE: In most cases, users should run linkgit:git-gc[1], which calls\n+git-prune. See the section \"NOTES\", below.\n+\n This runs `git-fsck --unreachable` using all the refs\n available in `$GIT_DIR/refs`, optionally with additional set of\n objects specified on the command line, and prunes all\n@@ -50,6 +53,23 @@ borrows from your repository via its\n $ git prune $(cd ../another && $(git-rev-parse --all))\n ------------\n \n+Notes\n+-----\n+\n+In most cases, users will not need to call git-prune directly, but\n+should instead call linkgit:git-gc[1], which handles pruning along with\n+many other housekeeping tasks.\n+\n+For a description of which objects are considered for pruning, see\n+git-fsck's --unreachable option.\n+\n+See Also\n+--------\n+\n+linkgit:git-fsck[1],\n+linkgit:git-gc[1],\n+linkgit:git-reflog[1]\n+\n Author\n ------\n Written by Linus Torvalds \n-- \n1.5.5.1.172.g4dce\n"},{"id":"75597","messageId":"7vskx45ncg.fsf@gitster.siamese.dyndns.org","threadId":"13229","inReplyTo":"20080429204514.GA21029@sigill.intra.peff.net","subject":"Re: [PATCH] Documentation: point git-prune users to git-gc","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-04-29T22:05:03Z","receivedAt":"2008-04-29T22:05:03Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> Yes, I don't think there is any reason for most people to use git-prune\n> at all, unless they are trying specifically to prune and don't want the\n> other gc effects to happen.\n>\n> Junio, please correct me if I'm wrong there.\n\nWell, this is a hard statement to make corrections to. If A is defined to\nbe a subset of B, and A is generally useful, the only reason to do B is\nwhen you want the effect of B without anything else. So your statement\ncannot be incorrect.\n\nHowever, in order to help people decide when to run B (or, if there ever\nbe a case where they might want to), there needs a discussion what other\nthings that _might_ be unwanted A does in addition to B.\n\nFor that reason,...\n\n> diff --git a/Documentation/git-prune.txt b/Documentation/git-prune.txt\n> index f151cff..f92bb8c 100644\n> --- a/Documentation/git-prune.txt\n> +++ b/Documentation/git-prune.txt\n> @@ -13,6 +13,9 @@ SYNOPSIS\n> DESCRIPTION\n> -----------\n> \n> +NOTE: In most cases, users should run linkgit:git-gc[1], which calls\n> +git-prune. See the section \"NOTES\", below.\n> +\n\nI think this note upfront is not helping readers very much (this is\ngit-prune documentation after all -- they are interested in the command\nand not gc), but ...\n\n> This runs `git-fsck --unreachable` using all the refs\n> available in `$GIT_DIR/refs`, optionally with additional set of\n> objects specified on the command line, and prunes all\n> @@ -50,6 +53,23 @@ borrows from your repository via its\n> $ git prune $(cd ../another && $(git-rev-parse --all))\n> ------------\n> \n> +Notes\n> +-----\n> +\n> +In most cases, users will not need to call git-prune directly, but\n> +should instead call linkgit:git-gc[1], which handles pruning along with\n> +many other housekeeping tasks.\n\n... this paragraph should be made a bit fatter by mentioning what \"other\nhousekeeping tasks\" are.\n\n> +For a description of which objects are considered for pruning, see\n> +git-fsck's --unreachable option.\n> +\n> +See Also\n> +--------\n> +\n> +linkgit:git-fsck[1],\n> +linkgit:git-gc[1],\n> +linkgit:git-reflog[1]\n> +\n> Author\n> ------\n> Written by Linus Torvalds \n> -- \n> 1.5.5.1.172.g4dce\n"},{"id":"75612","messageId":"20080429231917.GB22646@sigill.intra.peff.net","threadId":"13229","inReplyTo":"7vskx45ncg.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Documentation: point git-prune users to git-gc","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-04-29T23:19:17Z","receivedAt":"2008-04-29T23:19:17Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Apr 29, 2008 at 03:05:03PM -0700, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > Yes, I don't think there is any reason for most people to use git-prune\n> > at all, unless they are trying specifically to prune and don't want the\n> > other gc effects to happen.\n> >\n> > Junio, please correct me if I'm wrong there.\n> \n> Well, this is a hard statement to make corrections to. If A is defined to\n> be a subset of B, and A is generally useful, the only reason to do B is\n> when you want the effect of B without anything else. So your statement\n> cannot be incorrect.\n\nHeh. Sorry, I got very sloppy with my wording...there was an\n11-month-old child yelling in my ear. :)\n\nMy meaning was: \"people who want to clean up their repo but don't know\nthe right command stumble upon git-prune. They probably should be using\ngit-gc instead. People who know that they want to prune presumably know\nenough to ignore the warning note.\"\n\n> However, in order to help people decide when to run B (or, if there ever\n> be a case where they might want to), there needs a discussion what other\n> things that _might_ be unwanted A does in addition to B.\n\nFair enough.\n\n> > --- a/Documentation/git-prune.txt\n> > +++ b/Documentation/git-prune.txt\n> > @@ -13,6 +13,9 @@ SYNOPSIS\n> > DESCRIPTION\n> > -----------\n> > \n> > +NOTE: In most cases, users should run linkgit:git-gc[1], which calls\n> > +git-prune. See the section \"NOTES\", below.\n> > +\n> \n> I think this note upfront is not helping readers very much (this is\n> git-prune documentation after all -- they are interested in the command\n> and not gc), but ...\n\nI'm not so sure that they are interested in the prune command. At first\nI started with just a note near the end, but the point of this is\nspecifically to deal with users who \"stumble\" upon prune, either from\nreading the command list (i.e., trying to match a command to the\nobjective they want to perform) or from pre-gc tutorials or emails which\nmention it.\n\n> > +Notes\n> > +-----\n> > +\n> > +In most cases, users will not need to call git-prune directly, but\n> > +should instead call linkgit:git-gc[1], which handles pruning along with\n> > +many other housekeeping tasks.\n> \n> ... this paragraph should be made a bit fatter by mentioning what \"other\n> housekeeping tasks\" are.\n\nOK, I was trying to imply \"go look at git-gc for those tasks\" so they\ndidn't have to be repeated. Would you prefer it be spelled out\nexplicitly here, or is a more firm pointer OK?\n\n-Peff\n"},{"id":"75620","messageId":"7v63u040lb.fsf@gitster.siamese.dyndns.org","threadId":"13229","inReplyTo":"20080429231917.GB22646@sigill.intra.peff.net","subject":"Re: [PATCH] Documentation: point git-prune users to git-gc","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-04-30T01:01:52Z","receivedAt":"2008-04-30T01:01:52Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> I'm not so sure that they are interested in the prune command. At first\n> I started with just a note near the end, but the point of this is\n> specifically to deal with users who \"stumble\" upon prune, either from\n> reading the command list (i.e., trying to match a command to the\n> objective they want to perform) or from pre-gc tutorials or emails which\n> mention it.\n\nAh, you are right. People tend to stop reading when they _think_ they\nheard enough even though they haven't. The note upfront is good, and I\nsuspect we would not have to reword the latter parts either then.\n\n>> > +Notes\n>> > +-----\n>> > +\n>> > +In most cases, users will not need to call git-prune directly, but\n>> > +should instead call linkgit:git-gc[1], which handles pruning along with\n>> > +many other housekeeping tasks.\n>> \n>> ... this paragraph should be made a bit fatter by mentioning what \"other\n>> housekeeping tasks\" are.\n>\n> OK, I was trying to imply \"go look at git-gc for those tasks\" so they\n> didn't have to be repeated. Would you prefer it be spelled out\n> explicitly here, or is a more firm pointer OK?\n\nWill apply as is.\n\nThanks.\n"}]}