Martin Ågren writes:
> On 2 October 2017 at 08:30, Junio C Hamano wrote:
> ...
>> Thanks, both. Let's merge this to 'next' soonish.
>
> Thanks both of you for your comments. Based on them, I have made the
> following notes:
> ...
> Especially 9-11 make me feel like wanting to re-roll this, for
On 2 October 2017 at 08:30, Junio C Hamano wrote:
> Jeff King writes:
>
>> I've read through each and with the exception of patches 10 and 11, they
>> all look good to me.
>>
>> For 10 and 11, I think you've convinced me that the current behavior is
>> buggy. I do wonder if the subtleties might b
Jeff King writes:
> I've read through each and with the exception of patches 10 and 11, they
> all look good to me.
>
> For 10 and 11, I think you've convinced me that the current behavior is
> buggy. I do wonder if the subtleties might be easier to understand as a
> single patch, but I'm OK eith
On Sun, Oct 01, 2017 at 04:56:01PM +0200, Martin Ågren wrote:
> A recent series allowed `struct lock_file`s to be freed [1], so I wanted
> to get rid of the "simple" leaks of this kind. I found a couple of
> lock-related cleanups along the way and it resulted in this series. It
> feels a bit scary
Martin Ågren writes:
> Martin Ågren (11):
> sha1_file: do not leak `lock_file`
> treewide: prefer lockfiles on the stack
> lockfile: fix documentation on `close_lock_file_gently()`
> tempfile: fix documentation on `delete_tempfile()`
> cache-tree: simplify locking logic
> apply: move
A recent series allowed `struct lock_file`s to be freed [1], so I wanted
to get rid of the "simple" leaks of this kind. I found a couple of
lock-related cleanups along the way and it resulted in this series. It
feels a bit scary at eleven patches -- especially as this is about
locking -- but I hope
6 matches
Mail list logo
