Re: [RFC,PATCH] Make git prune remove temporary packs that look like write failures

On Feb 4, 2008 5:21 PM, Johannes Schindelin [off-list ref] wrote:

On Mon, 4 Feb 2008, David Tweed wrote:

quoted

In response to this and to Nico's earlier mail, I _think_ the usage with
repack is completely safe.

It would have been nicer of you to defend that, instead of sending me off
to look for myself.  Having looked for myself, I am not convinced at all.

I probably ought to have put the underlines around the "I". I'm
convinced, but since this is deleting things I'm more cautious than I
would be, say, parsing options.

And it would have been surprising: if your patch would play nicely with a
repack in progress, then it would fail to remove the temporary packs left
by a crashed repack.

I should been more careful what I said: I only use repack via "git gc"
which calls the repack as a subcommand. If the repack fails then the
whole process dies and you've got a dead tmp pack. The _next_ time you
call "git gc" it will do the repack, finish and then call "git prune"
(assuming --prune) and delete the temporary pack. Used in this way, I
have tried and I cannot see an execution path where this can go wrong.
You're right (and I didn't intend to suggest otherwise) that it would
be safe when running a "git prune" concurrently with a separate "git
repack".

However, I'm not familiar with what things like git-svn, cvs, etc, do.
Given that I've seen patches adding "git gc" periodically during
various imports, I wanted to someone who knows that area to confirm
the patch isn't violating any assumptions.

-- 
cheers, dave tweed__________________________
david.tweed@gmail.com
Rm 124, School of Systems Engineering, University of Reading.
"while having code so boring anyone can maintain it, use Python." --
attempted insult seen on slashdot