Re: [PATCH 3/5] refs.c: drop dead code checking lock status in `delete_pseudoref()`

2018-05-08 Thread Martin Ågren
On 8 May 2018 at 20:10, Jeff King wrote: > On Sun, May 06, 2018 at 04:10:29PM +0200, Martin Ågren wrote: >> Unlike in the previous patch, this function is not prepared for >> indicating errors via a `strbuf err`, so let's just drop the dead code. >> Any improved error-handling can

Re: [PATCH 3/5] refs.c: drop dead code checking lock status in `delete_pseudoref()`

2018-05-08 Thread Jeff King
On Sun, May 06, 2018 at 04:10:29PM +0200, Martin Ågren wrote: > After taking the lock we check whether we got it and die otherwise. But > since we take the lock using `LOCK_DIE_ON_ERROR`, we would already have > died. > > Unlike in the previous patch, this function is not prepared for >

Re: [PATCH 3/5] refs.c: drop dead code checking lock status in `delete_pseudoref()`

2018-05-06 Thread David Turner
Same concern here about staticness. On Sun, 2018-05-06 at 16:10 +0200, Martin Ågren wrote: > After taking the lock we check whether we got it and die otherwise. > But > since we take the lock using `LOCK_DIE_ON_ERROR`, we would already > have > died. > > Unlike in the previous patch, this

[PATCH 3/5] refs.c: drop dead code checking lock status in `delete_pseudoref()`

2018-05-06 Thread Martin Ågren
After taking the lock we check whether we got it and die otherwise. But since we take the lock using `LOCK_DIE_ON_ERROR`, we would already have died. Unlike in the previous patch, this function is not prepared for indicating errors via a `strbuf err`, so let's just drop the dead code. Any