On Sat, Jun 3, 2017 at 1:52 AM, Junio C Hamano <gits...@pobox.com> wrote: > Jeff King <p...@peff.net> writes: > >> But I think a more compelling case is that there may be an ongoing >> operation in the original repo (e.g., say you are in the middle of >> writing a commit message) when we do a blind copy of the filesystem >> contents. You might racily pick up a lockfile. >> >> Should we find and delete all *.lock files in the copied directory? That >> would get ref locks, etc. Half-formed object files are OK. Technically >> if you want to get an uncorrupted repository you'd also want to copy >> refs before objects (in case somebody makes a new object and updates a >> ref while you're copying). >> >> I don't know how careful it's worth being. I don't really _object_ to >> this patch exactly, but it does seem like it's picking up one random >> case (that presumably you hit) and ignoring all of the related cases. > > My feeling exactly. Diagnosing and failing upfront saying "well you > made a copy but it is not suitable for testing" sounds more sensible > at lesat to me.
This change makes the repo suitable for testing when it wasn't before. Yes, there are cases where there are other issues than index.lock preventing testing the repo, but I don't see why there shouldn't be a partial solution that solves a very common case in lieu of a perfect solution.
