Re: [BUG?] --boundary inconsistent with path limiting

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 4, 2016, 20:11 UTC
Message-ID: <xmqqr3a41eho.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20160804194043.z4nbosr4wpbzljdl@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 7 quoted lines

> 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).