From: Junio C Hamano <gitster@pobox.com>
Date: Tue, 06 Aug 2013 16:28:28 GMT
Subject: Re: [PATCH 4/4] fetch: opportunistically update tracking refs
Message-ID: <7vsiymhjgz.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20130511161652.GD3270@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

> @@ -170,6 +172,20 @@ static struct ref *get_ref_map(struct transport *transport,
>  			rm->fetch_head_status = FETCH_HEAD_MERGE;
>  		if (tags == TAGS_SET)
>  			get_fetch_map(remote_refs, tag_refspec, &tail, 0);
> +
> +		/*
> +		 * For any refs that we happen to be fetching via command-line
> +		 * arguments, take the opportunity to update their configured
> +		 * counterparts. However, we do not want to mention these
> +		 * entries in FETCH_HEAD at all, as they would simply be
> +		 * duplicates of existing entries.
> +		 */
> +		old_tail = tail;
> +		for (i = 0; i < transport->remote->fetch_refspec_nr; i++)
> +			get_fetch_map(ref_map, &transport->remote->fetch[i],
> +				      &tail, 0);
> +		for (rm = *old_tail; rm; rm = rm->next)
> +			rm->fetch_head_status = FETCH_HEAD_IGNORE;

Was there a reason why this change was done by appending new ref at
the tail of the ref_map list?  I would have expected that a naïve
and obvious implementation would be to iterate existing refs over
ref_map to find refs with an empty RHS whose LHS is configured to
usually store the fetched result to somewhere and to update their
RHS in place.

Being curious.