Re: [PATCH] prune: --expire=time

Linus Torvalds [off-list ref] writes:

However, now that rebasing ends up being visible in the branch reflog, 
we're back to the "normally nothing to ever prune" situation, and as such, 
the only object pruning that _should_ take place is basically as part of 
"git repack -a -d" (which unlike a prune is actually safe, since it only 
prunes objects that are reachable from a pack).

So to recap: "git prune" simply isn't a safe thing to do. Don't do it 
without thinking. I'm not at all sure it's a good idea that "git gc" does 
it for you, since it just encourages mindless pruning that probably 
shouldn't happen in the first place.

I guess we are in agreement on this.

-- >8 --
[PATCH] git-gc: do not run prune mindlessly.

Signed-off-by: Junio C Hamano <redacted>
---
 Documentation/git-gc.txt |    1 -
 git-gc.sh                |    1 -
 2 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/Documentation/git-gc.txt b/Documentation/git-gc.txt
index 2bcc949..f53ca97 100644
--- a/Documentation/git-gc.txt
+++ b/Documentation/git-gc.txt

@@ -50,7 +50,6 @@ kept.  This defaults to 15 days.
 
 See Also
 --------
-gitlink:git-prune[1]
 gitlink:git-reflog[1]
 gitlink:git-repack[1]
 gitlink:git-rerere[1]

diff --git a/git-gc.sh b/git-gc.sh
index 6de55f7..7716f62 100755
--- a/git-gc.sh
+++ b/git-gc.sh

@@ -11,5 +11,4 @@ SUBDIRECTORY_OK=Yes
 git-pack-refs --prune &&
 git-reflog expire --all &&
 git-repack -a -d -l &&
-git-prune &&
 git-rerere gc || exit

-- 
1.5.0.rc2

On Sun, 21 Jan 2007, Junio C Hamano wrote:

quoted

So to recap: "git prune" simply isn't a safe thing to do. Don't do it 
without thinking. I'm not at all sure it's a good idea that "git gc" does 
it for you, since it just encourages mindless pruning that probably 
shouldn't happen in the first place.

I guess we are in agreement on this.

Well, having complained about "git prune", I at the same time have to 
admit that I worry about loose objects (and scary messages from 
git-fsck-objects) potentially confusing new people.

So "git prune" _does_ remove stuff that happens normally. It removes stuff 
that accumulates (even with reflog) thanks to commands that were 
interrupted with ^C, and it also removes the auto-merge turds that the 
recursive merge can create when it does its internal pseudo-commit for 
more complex merges.

So I don't think running "prune" from within "git gc" is necessarily 
wrong per se - I just don't think it's a good idea to do so by _default_, 
exactly because of the issues it can have. 

So hiding "git prune" behind "git gc" is probably a good thing (make 
people learn just one thing they need to interface to), but maybe we need 
a "--prune" flag to the gc command, and then perhaps just document that 
you should be careful.

		Linus

It doesn't call git-prune, and it does call a lot of other things.

Signed-off-by: Jeff King <redacted>
---
On Sun, Jan 21, 2007 at 06:40:40PM -0800, Junio C Hamano wrote:

[PATCH] git-gc: do not run prune mindlessly.

This updates the release notes to reflect this change (and fixes a few
other inaccuracies and omissions).

 v1.5.0.txt |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/v1.5.0.txt b/v1.5.0.txt
index 1b8ecf0..8a2c9cc 100644
--- a/v1.5.0.txt
+++ b/v1.5.0.txt

@@ -191,8 +191,8 @@ Updates in v1.5.0 since v1.4.4 series
    unreachable, as there is a one-day grace period built-in.
 
  - There is a toplevel garbage collector script, 'git-gc', that
-   is an easy way to run 'git-repack -a -d', 'git-reflog gc',
-   and 'git-prune'.
+   runs periodic cleanup functions, including 'git-repack -a -d',
+   'git-reflog expire', 'git-pack-refs --prune', and 'git-rerere gc'.
 
 
 * Detached HEAD

-- 
1.5.0.rc1.gda86