Documentation: git-prune

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... Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago · c82365dc6f
1 changed files with 29 additions and 1 deletions
--- a/Documentation/git-prune.txt
+++ b/Documentation/git-prune.txt
@ -8,7 +8,7 @@ git-prune - Prunes all unreachable objects from the object database
 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
 ------