Re: [PATCH] prune: --expire=time
- From
Linus Torvalds <torvalds@osdl.org>
- Date
- Jan 22, 2007, 02:58 UTC
- Message-ID
- <Pine.LNX.4.64.0701211851310.14248@woody.osdl.org>
- In-Reply-To
- <7virezwzpz.fsf@assigned-by-dhcp.cox.net>
On Sun, 21 Jan 2007, Junio C Hamano wrote:
Show 7 quoted lines
> > > > 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