merge: clarify collect_parents() logic
authorJunio C Hamano <gitster@pobox.com>
Sat, 25 Apr 2015 17:25:43 +0000 (10:25 -0700)
committerJunio C Hamano <gitster@pobox.com>
Wed, 29 Apr 2015 20:17:53 +0000 (13:17 -0700)
commit0b10b8a3d53c7aaf42b8f14da1021ea59ea4e0ec
tree70bf1bd5fdb5083c937e663c5a8f595b52aec5b0
parent1016658de3fe213eedebdb478cca0324ac8fbe87
merge: clarify collect_parents() logic

Clarify this small function in three ways.

 - The function initially collects all commits to be merged into a
   commit_list "remoteheads"; the "remotes" pointer always points at
   the tail of this list (either the remoteheads variable itself, or
   the ->next slot of the element at the end of the list) to help
   elongate the list by repeated calls to commit_list_insert().
   Because the new element appended by commit_list_insert() will
   always have its ->next slot NULLed out, there is no need for us
   to assign NULL to *remotes to terminate the list at the end.

 - The variable "head_subsumed" always confused me every time I read
   this code.  What is happening here is that we inspect what the
   caller told us to merge (including the current HEAD) and come up
   with the list of parents to be recorded for the resulting merge
   commit, omitting commits that are ancestor of other commits.
   This filtering may remove the current HEAD from the resulting
   parent list---and we signal that fact with this variable, so that
   we can later record it as the first parent when "--no-ff" is in
   effect.

 - The "parents" list is created for this function by reduce_heads()
   and was not deallocated after its use, even though the loop
   control was written in such a way to allow us to do so by taking
   the "next" element in a separate variable so that it can be used
   in the next-step part of the loop control.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin/merge.c