{"thread":{"id":"43007","subject":"[BUG?] --boundary inconsistent with path limiting","startedAt":"2016-08-04T19:41:02Z","lastAt":"2016-08-04T20:11:23Z","messageCount":3,"participants":["Jeff King","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"293121","messageId":"20160804194043.z4nbosr4wpbzljdl@sigill.intra.peff.net","threadId":"43007","inReplyTo":null,"subject":"[BUG?] --boundary inconsistent with path limiting","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-08-04T19:40:43Z","receivedAt":"2016-08-04T19:41:02Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"Let's say I have a simple repo with three paths:\n\n\tgit init -q repo\n\tcd repo\n\tfor i in a b c\n\tdo\n\t\techo content >$i.t\n\t\tgit add $i.t\n\t\tgit commit -qm $i &&\n\t\tgit tag $i\n\tdone\n\nIf I ask for the top 2 commits, with the third as a boundary, I get the\nexpected output:\n\n  $ git log --format='%m %s' --boundary a..c\n  > c\n  > b\n  - a\n\nIf I limit the path to \"b.t\", I get:\n\n  $ git log --format='%m %s' --boundary a..c -- b.t\n  > b\n  - a\n\nThat makes sense to me. We omit \"c\" because it doesn't touch \"b.t\", and\nobviously include \"b\", which does. We _do_ include the boundary commit,\neven though it doesn't touch the path, which makes sense to me. It\nremains a boundary whether it touched the path or not, and without it,\nwe get no boundary at all.\n\nBut now if I limit to \"a.t\", I get no output at all:\n\n  $ git log --format='%m %s' --boundary a..c -- a.t\n\nwhereas I would have expected \"- a\" to show the boundary.\n\nIs this a bug, or are my expectations wrong?\n\n-Peff\n"},{"id":"293133","messageId":"20160804200905.7xdiei2yfv2aw6im@sigill.intra.peff.net","threadId":"43007","inReplyTo":"20160804194043.z4nbosr4wpbzljdl@sigill.intra.peff.net","subject":"Re: [BUG?] --boundary inconsistent with path limiting","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-08-04T20:09:05Z","receivedAt":"2016-08-04T20:09:14Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Aug 04, 2016 at 03:40:43PM -0400, Jeff King wrote:\n\n> That makes sense to me. We omit \"c\" because it doesn't touch \"b.t\", and\n> obviously include \"b\", which does. We _do_ include the boundary commit,\n> even though it doesn't touch the path, which makes sense to me. It\n> remains a boundary whether it touched the path or not, and without it,\n> we get no boundary at all.\n> \n> But now if I limit to \"a.t\", I get no output at all:\n> \n>   $ git log --format='%m %s' --boundary a..c -- a.t\n> \n> whereas I would have expected \"- a\" to show the boundary.\n> \n> Is this a bug, or are my expectations wrong?\n\nSo I suppose it depends how you define \"boundary\" commits. In\nget_revision_internal(), I see this comment:\n\n        /*\n         * boundary commits are the commits that are parents of the\n         * ones we got from get_revision_1() but they themselves are\n         * not returned from get_revision_1().  Before returning\n         * 'c', we need to mark its parents that they could be boundaries.\n         */\n\nBy that definition, obviously if we do not have any commits to show,\nthen we have no boundary commits. I don't think this definition is\nanywhere in the user-facing documentation, though.\n\nIt still seems weird to me, and I wonder if we should show all\nUNINTERESTING commits as boundaries in the case that we haven't produced\nany positive commits at all. But perhaps there is a case where that\nwould not be desirable.\n\n-Peff\n"},{"id":"293134","messageId":"xmqqr3a41eho.fsf@gitster.mtv.corp.google.com","threadId":"43007","inReplyTo":"20160804194043.z4nbosr4wpbzljdl@sigill.intra.peff.net","subject":"Re: [BUG?] --boundary inconsistent with path limiting","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-08-04T20:11:15Z","receivedAt":"2016-08-04T20:11:23Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> But now if I limit to \"a.t\", I get no output at all:\n>\n>   $ git log --format='%m %s' --boundary a..c -- a.t\n>\n> whereas I would have expected \"- a\" to show the boundary.\n>\n> Is this a bug, or are my expectations wrong?\n\nIn a range a..c, there is nothing that touches the path, so there is\nno positive outcome.  As boundaries are essentially the parents of\nthe \"last\" positive outcome, I would not be surprised if I see an\nempty output in that scenario.\n\nBut to be honest, I do not think anybody cared between the\ndistinction between a bug and intended behaviour in this case.\n\nThe boundary started as a debugging aid for the traversal machinery\nand not as a serious feature to support end-user workflow.  In its\nearly days, I do not think we even showed _all_ boundaries (instead\nwe showed only ones that we have already parsed, or something like\nthat).  I think we added code to do a bit more work when asked to\nshow boundaries to show boundary commits that the traditional\n\"primarily for debugging\" logic wouldn't have shown later, losing\nits value as a debugging aid (because it no longer showed precisely\nwhere the traversal machinery stopped digging).\n\n\n\n"}]}