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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html