From: Junio C Hamano <gitster@pobox.com>
Date: Thu, 04 Aug 2016 20:11:15 GMT
Subject: Re: [BUG?] --boundary inconsistent with path limiting
Message-ID: <xmqqr3a41eho.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20160804194043.z4nbosr4wpbzljdl@sigill.intra.peff.net>

Jeff King <peff@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).