1. Stefan Saasen
  2. git


Junio C Hamano  committed c82365d

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>

  • Participants
  • Parent commits 8c667f4
  • Branches master

Comments (0)

Files changed (1)

File Documentation/git-prune.txt

View file
  • Ignore whitespace
-'git-prune' [-n]
+'git-prune' [-n] [--] [<head>...]
 	Do not remove anything; just report what it would
+	Do not interpret any more arguments as options.
+	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.
+To prune objects not used by your repository and another that
+borrows from your repository via its
+$ git prune $(git-rev-parse --all) \
+  $(cd ../another && $(git-rev-parse --all))