On Feb 4, 2008 5:21 PM, Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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@xxxxxxxxx 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 - 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
