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

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

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