Re: [PATCH 04/22] rollback_lock_file(): set fd to -1

2014-04-07 Thread Junio C Hamano
Michael Haggerty writes: > The first use of a lock_file object necessarily passes through > lock_file(). The only precondition for that function is that the > on_list field is zero, which is satisfied by a xcalloc()ed object. > > Subsequent uses of a lock_file object must *not* zero the object.

Re: [PATCH 04/22] rollback_lock_file(): set fd to -1

2014-04-06 Thread Michael Haggerty
On 04/02/2014 06:58 PM, Junio C Hamano wrote: > Jeff King writes: > >> On Tue, Apr 01, 2014 at 05:58:12PM +0200, Michael Haggerty wrote: >> >>> When rolling back the lockfile, call close_lock_file() so that the >>> lock_file's fd field gets set back to -1. This could help prevent >>> confusion i

Re: [PATCH 04/22] rollback_lock_file(): set fd to -1

2014-04-02 Thread Junio C Hamano
Jeff King writes: > On Tue, Apr 01, 2014 at 05:58:12PM +0200, Michael Haggerty wrote: > >> When rolling back the lockfile, call close_lock_file() so that the >> lock_file's fd field gets set back to -1. This could help prevent >> confusion in the face of hypothetical future programming errors. >

Re: [PATCH 04/22] rollback_lock_file(): set fd to -1

2014-04-01 Thread Jeff King
On Tue, Apr 01, 2014 at 05:58:12PM +0200, Michael Haggerty wrote: > When rolling back the lockfile, call close_lock_file() so that the > lock_file's fd field gets set back to -1. This could help prevent > confusion in the face of hypothetical future programming errors. This also solves a race. W

[PATCH 04/22] rollback_lock_file(): set fd to -1

2014-04-01 Thread Michael Haggerty
When rolling back the lockfile, call close_lock_file() so that the lock_file's fd field gets set back to -1. This could help prevent confusion in the face of hypothetical future programming errors. Signed-off-by: Michael Haggerty --- lockfile.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion