Junio C Hamano <junkio@cox.net> 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] [--] [<head>...] DESCRIPTION ----------- @@ -27,6 +27,34 @@ OPTIONS Do not remove anything; just report what it would remove. +--:: + Do not interpret any more arguments as options. + +<head>...:: + Instead of keeping objects + reachable from any of our references, keep objects + reachable from only listed <head>s. ++ +Note that the explicitly named <head>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 ------ - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.htmlReceived on Fri Dec 09 11:28:55 2005
This archive was generated by hypermail 2.1.8 : 2005-12-09 11:29:02 EST