From: David Tweed Date: Mon, 04 Feb 2008 17:39:43 GMT Subject: Re: [RFC,PATCH] Make git prune remove temporary packs that look like write failures Message-ID: In-Reply-To: On Feb 4, 2008 5:21 PM, Johannes Schindelin 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