Jeff King <p...@peff.net> writes:
> There's no need to make this get_revision_1 call when our
> counter runs out. If we are not in --boundary mode, we will
> just throw away the result and immediately return NULL. If
> we are in --boundary mode, then we will still throw away the
> result, and then start showing the boundary commits.
>
> However, as git_revision_1 does not impact the boundary
> list, it should not have an impact.
We used to reset 'c' to NULL ("throw away the result"), run
create_boundary_commit_list(), and ask ourselves to pop the boundary
it computed.
Now we don't call get_revision_1() and leave 'c' to NULL as
initialized ("avoid work"), and do the same.
The state create_boundary_commit_list() sees would slightly be
different, as we used to dig one level deeper, smudging more commits
with bits, but the only bits that may be smudged by this digging
that may matter in create_commit_list() is CHILD_SHOWN and SHOWN,
but by definition the commits around the commit the extra call to
get_revision_1() would have returned are marked with neither during
that extra call, so I think this conversion does not affect the
boundary list.
So I think I like this change. If anything, it makes the loop
structure simpler and a bit easier to understand.
--
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
