On Wed, Oct 01, 2014 at 01:14:46PM +0200, Michael Haggerty wrote: > This series applies on top of the series "Lockfile correctness and > refactoring" (Junio's branch mh/lockfile). > > There are already two callers that write to lockfiles using stdio. But > they currently need intimate knowledge of the lockfile implementation > to work correctly; for example, they have to call fclose() themselves > and set lk->fd to -1 to prevent the file from being closed again. This > is awkward and error-prone. I think it's also wrong on systems where you cannot delete an open file. A signal or atexit handler will not be able to close the file (since it does not know the fd), and the unlink() will fail. IIRC, either cygwin or msysgit (or both?) is such a platform. > Michael Haggerty (3): > fdopen_lock_file(): access a lockfile using stdio > dump_marks(): reimplement using fdopen_lock_file() > commit_packed_refs(): reimplement using fdopen_lock_file() I had a few minor comments on the first patch, but I would also be OK with it going in as-is. The other two looked fine to me. Thanks for working on this. -Peff -- 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