Jeff King <p...@peff.net> writes:
> But now if I limit to "a.t", I get no output at all:
> $ git log --format='%m %s' --boundary a..c -- a.t
> whereas I would have expected "- a" to show the boundary.
> Is this a bug, or are my expectations wrong?
In a range a..c, there is nothing that touches the path, so there is
no positive outcome. As boundaries are essentially the parents of
the "last" positive outcome, I would not be surprised if I see an
empty output in that scenario.
But to be honest, I do not think anybody cared between the
distinction between a bug and intended behaviour in this case.
The boundary started as a debugging aid for the traversal machinery
and not as a serious feature to support end-user workflow. In its
early days, I do not think we even showed _all_ boundaries (instead
we showed only ones that we have already parsed, or something like
that). I think we added code to do a bit more work when asked to
show boundaries to show boundary commits that the traditional
"primarily for debugging" logic wouldn't have shown later, losing
its value as a debugging aid (because it no longer showed precisely
where the traversal machinery stopped digging).
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