Re: [PATCH v3 1/3] refs/files-backend: add longer-scoped copy of string to list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jeff King <peff@xxxxxxxx> writes:

> I noticed the HEAD funniness, too, when looking at this earlier. I agree
> with Junio that it's not quite consistent with the general rule of
> "string list items point to their refnames", but I don't think it
> matters in practice.

Yup, we are on the same page; the "fix" I was alluding to would look
exactly like what you wrote below, but I agree the distinction does
not matter in practice.  IOW, I do not think the code after Martin's
fix is wrong per-se.

Thanks.

> I think the fix, if we wanted to do one, would be similar to what you
> did in split_symref_update(). Like:
>
> diff --git a/refs/files-backend.c b/refs/files-backend.c
> index f3455609d6..3f9deff902 100644
> --- a/refs/files-backend.c
> +++ b/refs/files-backend.c
> @@ -2095,8 +2095,7 @@ static int split_head_update(struct ref_update *update,
>  	 * transaction. This insertion is O(N) in the transaction
>  	 * size, but it happens at most once per transaction.
>  	 */
> -	item = string_list_insert(affected_refnames, "HEAD");
> -	if (item->util) {
> +	if (string_list_has_string(affected_refnames, "HEAD")) {
>  		/* An entry already existed */
>  		strbuf_addf(err,
>  			    "multiple updates for 'HEAD' (including one "
> @@ -2111,6 +2110,7 @@ static int split_head_update(struct ref_update *update,
>  			update->new_oid.hash, update->old_oid.hash,
>  			update->msg);
>  
> +	item = string_list_insert(affected_refnames, new_update->refname);
>  	item->util = new_update;
>  
>  	return 0;
>
> -Peff



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux