Jeff King <p...@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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
