Re: [PATCH 2/2] match_refs: search ref list tail internally

Clemens Buchacher <drizzd@aon.at> writes:

The existing program (and the result after the patch) open-codes too much inside the huge main() function, and it is extremely painful to follow what is going on.

But it is not that "the NULL test was redundant" that I'd be worried about. In that unreadable main() function:

 - get_dav_remote_heads() is called, which asks the other end what the
   remote refs are; the result is queued in the linked list whose head is
   remote_refs and tail is remote_tail;

 - the resulting remote_tail is given to match_refs() to further grow the
   linked list.  The function will queue new "struct ref" instances
   (e.g. by making a call to match_explicit_refs()) at the end of the
   list.

   The caller used to pass "here is the end of the list" variable to it,
   but now you compute (perhaps redundantly) the end of the ref list by
   tangling from dst to its tail, yourself, and match_refs() links new
   elements at the tail of the list correctly.

   But what happens to the calling program's remote_tail variable after
   match_refs() returns?  The code used to guarantee that it always point
   at the real end of the list, but that guarantee is now gone.

It so happens that http-push.c never looked at remote_tail to do further processing on the list after match_refs() returned, and that is why your patch does not break http-push.c. Any third-party patch to http-push.c that relied on the old guarantee will textually merge cleanly but will subtly break with this change.

Other parts of this patch removes the local "remote_tail" variables, and it is very clear that they do not have this problem; any third-parth patch will break if they used remote_tail after match_refs() returned, so this change is a safe one for them.

I wonder what interaction this change will have with the http-push clean-up Ray Chuan has been working on...