Jeff King wrote:
> Signed-off-by: Ronnie Sahlberg
> Signed-off-by: Jeff King
> ---
> refs.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
Reviewed-by: Jonathan Nieder
(modulo the author attribution nit you noticed)
--
To unsubscribe from this list: send the line "unsubsc
On Wed, Nov 19, 2014 at 02:34:12PM -0800, Junio C Hamano wrote:
> > Subject: lock_ref_sha1_basic: do not die on locking errors
>
> Will queue; thanks.
I just noticed that when I pasted it into the mail, I dropped the
From: Ronnie Sahlberg
header. Can you please make sure to credit Ronnie as
Jeff King writes:
> So we still have to keep the last_errno handling in error_return.
> Meaning that we need to drop patch 2 (even though the other cases don't
> need errno saved/restore, since the goto does it unconditionally, we
> still need to set last_errno). And therefore patch 1 is not help
On Tue, Nov 18, 2014 at 06:07:13PM -0800, Jonathan Nieder wrote:
> Jeff King wrote:
>
> > Hmph. Should we just abandon my series in favor of taking Ronnie's
> > original patch, then? We can apply the "save/restore errno in error()"
> > patch independently if we like.
>
> I liked patches 1 and 2
Jonathan Nieder writes:
> Jeff King wrote:
>
>> Hmph. Should we just abandon my series in favor of taking Ronnie's
>> original patch, then? We can apply the "save/restore errno in error()"
>> patch independently if we like.
>
> I liked patches 1 and 2 and the explanation from patch 4. Perhaps
>
Jeff King wrote:
> Hmph. Should we just abandon my series in favor of taking Ronnie's
> original patch, then? We can apply the "save/restore errno in error()"
> patch independently if we like.
I liked patches 1 and 2 and the explanation from patch 4. Perhaps
patch 3 should be replaced with a pat
On Tue, Nov 18, 2014 at 06:00:09PM -0800, Jonathan Nieder wrote:
> Jeff King wrote:
>
> > For most errors, we jump to a goto label that unlocks the
> > ref and returns NULL. However, in none of these error paths
> > would we ever have actually locked the ref. By the time we
> > actually take the
Jeff King wrote:
> For most errors, we jump to a goto label that unlocks the
> ref and returns NULL. However, in none of these error paths
> would we ever have actually locked the ref. By the time we
> actually take the lock, we follow a different path that does
> not ever hit this goto (we rely o
For most errors, we jump to a goto label that unlocks the
ref and returns NULL. However, in none of these error paths
would we ever have actually locked the ref. By the time we
actually take the lock, we follow a different path that does
not ever hit this goto (we rely on verify_lock to unlock if
i
9 matches
Mail list logo
