Re: [PATCH v3 1/3] refs/files-backend: add longer-scoped copy of string to list
- Date: Tue, 05 Sep 2017 19:02:55 +0900
- From: Junio C Hamano <gitster@xxxxxxxxx>
- Subject: Re: [PATCH v3 1/3] refs/files-backend: add longer-scoped copy of string to list
Martin Ågren <martin.agren@xxxxxxxxx> writes:
> On 30 August 2017 at 04:52, Michael Haggerty <mhagger@xxxxxxxxxxxx> wrote:
>> v3 looks good to me. Thanks!
>> Reviewed-by: Michael Haggerty <mhagger@xxxxxxxxxxxx>
> Thank _you_ for very helpful feedback on the earlier versions.
Yes, the earlier attempt was sort-of barking up a wrong tree.
Once we step back and observe other users of affected_refnames and
realize that the list is meant to to point at a refname field of an
existing instance of another structure by borrowing, the blame
shifts from files_transaction_prepare() to the real culprit.
Michael's review gave us a very good "let's step back a bit" that
made the huge improvement between v1 and v2/v3.
I wonder if we should be tightening the use of affected_refnames
even further, though.
It is may be sufficient to make sure that we do not throw anything
that we would need to free as part of destroying affected_refnames
into the string list, purely from the "leak prevention" perspective.
But stepping back a bit, the reason why the string list exists in
the first place is to make sure we do not touch the same ref twice
in a single transaction, the set of all possible updates in the
single transaction exists somewhere, and each of these updates know
what ref it wants to update.
And that is recorded in transaction->updates->refname no?
So it seems to me that logically any and all string that is
registered in affected_refnames list must be the refname field of
a ref_update structure in the transaction.
And from that point of view, doesn't split_head_update() wants a
similar fix? It attempts to insert "HEAD", makes sure it hasn't
been inserted and then hangs a new update transaction as its util.
It is not wrong per-se from purely leak-prevention point of view,
as that "HEAD" is a literal string we woudn't even want to free,
but from logical/"what each data means" point of view, it still