Jeff King <p...@peff.net> writes:

> Yeah, this was my analysis, too. Though reading get_revision-1, it seems
> like we can actually set SHOWN, but I wasn't able to trigger any change
> of behavior in practice. I think it is because we must set both SHOWN
> and BOUNDARY to have an effect, and we do not do so.

In principle, SHOWN is only given when get_revision_internal gives
the commit back to be shown, and the parents of the returned commit
are painted CHILD_SHOWN.  This should be the only place to paint
commit as CHILD_SHOWN.

A handful of places set the bit to commits that would be shown if
some options that further limit what is shown by topological
property (e.g. --left-only, --cherry-pick), which may cause that a
parent of a commit that was omitted due to these conditions may
later be marked incorrectly as a boundary inside
create_boundary_commit_list().

BOUNDARY is only given in create_boundary_commit_list() using
CHILD_SHOWN and SHOWN, and that should happen only once when
get_revision_1() runs out of the commits.

By the way, cherry_pick_list() pays attention to BOUNDARY, but I
think it is written overly defensively to protect itself from future
callsites.  With the current code structure, it is only called from
limit_list() and get_revision_*() functions are never called until
limit_list() returns (and again create_boundary_commit_list() that
is called from get_revision_internal() is the only place that sets
BOUNDARY, so the commits cherry_pick_list() sees would never have
that bit set.

> So the only questionable thing would be: are there commits with BOUNDARY
> set but not SHOWN that could be affected by calling get_revision_1? For
> that matter, if such a commit existed, would the current behavior even
> be correct? We would not have actually shown the commit, so if such a
> case did exist, I wonder if we would be fixing a bug.
--
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

Reply via email to