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

[Junio C Hamano <gitster@pobox.com>]

Clemens Buchacher <drizzd@aon.at> writes:

> Avoid code duplication by moving list tail search to match_refs().
>
> This does not change the semantics, not even for http-push. The NULL
> test for remote_tail was redundant.

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...