From: Junio C Hamano Date: Fri, 09 Dec 2005 00:28:20 GMT Subject: Re: [PATCH 6/17] Document the [...] and -- arguments to git-prune. Message-ID: <7voe3r9krf.fsf@assigned-by-dhcp.cox.net> In-Reply-To: <7vzmnb9m7w.fsf@assigned-by-dhcp.cox.net> Junio C Hamano writes: > Come to think of it, why would anybody want to pass heads > explicitly? It seems to me that it would allow you to _lose_ > objects referenced only from omitted branches... Not replacing but always including our own refs may be more desirable (and unarguably much safer), but at the same time I have a suspicion that that might be forbidding a useful usage I haven't thought of, so... --- diff --git a/Documentation/git-prune.txt b/Documentation/git-prune.txt index 3367c9b..05c8d49 100644 --- a/Documentation/git-prune.txt +++ b/Documentation/git-prune.txt @@ -8,7 +8,7 @@ git-prune - Prunes all unreachable objec SYNOPSIS -------- -'git-prune' [-n] +'git-prune' [-n] [--] [...] DESCRIPTION ----------- @@ -27,6 +27,34 @@ OPTIONS Do not remove anything; just report what it would remove. +--:: + Do not interpret any more arguments as options. + +...:: + Instead of keeping objects + reachable from any of our references, keep objects + reachable from only listed s. ++ +Note that the explicitly named s are *not* appended to the +default set of references, but they replace them. In general you +would want to say `git prune $(git-rev-parse --all) extra1 +extra2` to keep chains of commits leading to extra1, extra2, +... in addition to what are reachable from your own refs. +Saying `git prune extra1 extra2` would *lose* objects reachable +only from the usual refs, which is usually not what you want. + + +EXAMPLE +------- + +To prune objects not used by your repository and another that +borrows from your repository via its +`.git/objects/info/alternates`: + +------------ +$ git prune $(git-rev-parse --all) \ + $(cd ../another && $(git-rev-parse --all)) +------------ Author ------