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>
This commit is contained in:
Junio C Hamano 2005-12-08 16:30:24 -08:00
Родитель 8c667f4bb8
Коммит c82365dc6f
1 изменённых файлов: 29 добавлений и 1 удалений

Просмотреть файл

@ -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
------