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

["David Tweed" <david.tweed@gmail.com>]

On Feb 4, 2008 5:21 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Mon, 4 Feb 2008, David Tweed wrote:

> > 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