diff options
author | Junio C Hamano <gitster@pobox.com> | 2015-04-25 10:25:43 -0700 |
---|---|---|
committer | Junio C Hamano <gitster@pobox.com> | 2015-04-29 13:17:53 -0700 |
commit | 0b10b8a3d53c7aaf42b8f14da1021ea59ea4e0ec (patch) | |
tree | 70bf1bd5fdb5083c937e663c5a8f595b52aec5b0 /Documentation/gitcore-tutorial.txt | |
parent | merge: small leakfix and code simplification (diff) | |
download | tgif-0b10b8a3d53c7aaf42b8f14da1021ea59ea4e0ec.tar.xz |
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>
Diffstat (limited to 'Documentation/gitcore-tutorial.txt')
0 files changed, 0 insertions, 0 deletions