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

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

This case does not need any locking, as blobs reachable from
index are considered as "reachable" for the purpose of pruning.

Well, strictly speaking, there's a race there. The new index gets written 
out _after_ the blob has been created. Also, in many cases, we end up 
using completely temporary indexes ("git commit filename") that "git 
prune" doesn't know or understand.

All of which is really nothing new. "git prune" has always been dangerous. 
You cannot, and must not, run it concurrently with other git operations.

Also, in the absense of undo operations, there is really nothing to ever 
prune. Of course, the git.git archive itself has effectively taughth 
people bad habits, since "pu" ends up continually rebasing itself. 

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.

Needing to prune is generally to be taken as a sign of something being 
wrong.

(And yeah, the grace period makes it "safe". Assuming everybody involved 
has even half-way reliable clocks. So IN PRACTICE it is all fine, and I 
doubt you can lose anything except by really doing something insane. If 
you want to kill your archive, it's easier to do "rm .git/objects/*/*a*" 
than it is to try to do it with strange "git prune" setups, but still..)

		Linus