On Thu, Feb 9, 2017 at 4:11 AM, Junio C Hamano wrote:
> With or without the patch in this thread, parse_pathspec() behaves
> the same way for either CWD or FULL if you feed a non-empty
> pathspec with at least one positive element. IOW, if a caller feeds
> a non-empty pathspec and there is no "ne
On Thu, Feb 9, 2017 at 12:39 AM, Junio C Hamano wrote:
> Duy Nguyen writes:
>
>> On Wed, Feb 8, 2017 at 12:12 PM, Linus Torvalds
>> wrote:
>>> Two-patch series to follow.
>>
>> glossary-content.txt update for both patches would be nice.
>
> I am no longer worried about it as I saw somebody actua
Junio C Hamano writes:
> If you know offhand which callers pass neither of the two
> PATHSPEC_PREFER_* bits and remember for what purpose you allowed
> them to do so, please remind me. I'll keep digging in the meantime.
Answering my own questions, here are my findings so far and a
tentative con
Duy Nguyen writes:
> On Wed, Feb 8, 2017 at 12:12 PM, Linus Torvalds
> wrote:
>> Two-patch series to follow.
>
> glossary-content.txt update for both patches would be nice.
I am no longer worried about it as I saw somebody actually sent
follow-up patches on this, but I want to pick your brain o
On Wed, Feb 8, 2017 at 12:12 PM, Linus Torvalds
wrote:
> Two-patch series to follow.
glossary-content.txt update for both patches would be nice.
--
Duy
On Tue, 7 Feb 2017, Junio C Hamano wrote:
> > + // Special case alias for '!'
>
> /* style? */
Will fix.
> I somehow do not think this is correct. I expect
>
> cd t && git grep -e foo -- :^perf/
>
> to look into things in 't' except for things in 't/perf', but the
> above wi
Linus Torvalds writes:
> People don't expect set theory from their pathspecs. They expect their
> pathspecs to limit the output. They've learnt that within a
> subdirectory, the pathspec limits to that subdirectory. And now it
> suddenly starts showing things outside the subdirectory?
>
> At that
On Tue, Feb 7, 2017 at 7:12 PM, Junio C Hamano wrote:
>
> But that is not what I was talking about. Let's simplify. I'd say
> for any command that acts on "everything" when pathspec is not
> given, the two sets of actual paths affected by these two:
>
> git cmd -- "net/"
> git cm
Linus Torvalds writes:
> No. The thing is, "git diff" is relative too - for path
> specifications. And the negative entries are pathspecs - and they act
> as relative ones.
>
> IOW, that whole
>
> cd drivers
> git diff A..B -- net/
>
> will actually show the diff for drivers/net - so the path
On Tue, Feb 07, 2017 at 05:48:26PM -0800, Linus Torvalds wrote:
>
>
> On Tue, 7 Feb 2017, Linus Torvalds wrote:
> >
> > [ Clarification from original message, since Junio asked: I didn't
> > actually want the semantics of '.' at all, since in a subdirectory it
> > limits to the current subdi
On Tue, Feb 07, 2017 at 06:49:24PM -0800, Linus Torvalds wrote:
> On Tue, Feb 7, 2017 at 6:40 PM, Mike Hommey wrote:
> >
> > As such, the default positive match should be ':/' (which is shorter and
> > less cumbersome than ':(top)', btw)
>
> So that's what my patch does.
>
> However, it's actual
On Tue, Feb 7, 2017 at 6:42 PM, Junio C Hamano wrote:
>
> 1. I think some commands limit their operands to cwd and some work
> on the whole tree when given no pathspec. I think the "no
> positive? then let's give you everything except these you
> excluded" should base the definition
On Tue, Feb 7, 2017 at 6:40 PM, Mike Hommey wrote:
>
> As such, the default positive match should be ':/' (which is shorter and
> less cumbersome than ':(top)', btw)
So that's what my patch does.
However, it's actually very counter-intuitive in a subdirectory.
Git doesn't do much of that, but l
Linus Torvalds writes:
> So here's an RFC patch, and I'm quoting the above part of my thinking
> because it's what the patch does, but it turns out that it's probably not
> what we want, and I suspect the "." behavior (as opposed to "no filtering
> at all") is actually better.
> ...
>
> Commen
On Tue, 7 Feb 2017, Linus Torvalds wrote:
>
> [ Clarification from original message, since Junio asked: I didn't
> actually want the semantics of '.' at all, since in a subdirectory it
> limits to the current subdirectory. So I'd suggest that in the absence
> of any positive pattern, there
Linus Torvalds writes:
> [ Duh, I sent this just to Junio initially due to a brainfart. Here
> goes the list also ]
And my earlier response goes to the list ;-)
Linus Torvalds writes:
> Most of the time when I use pathspecs, I just use the bog-standard
> normal ones, and everything works wond
[ Duh, I sent this just to Junio initially due to a brainfart. Here
goes the list also ]
Most of the time when I use pathspecs, I just use the bog-standard
normal ones, and everything works wonderfully.
But then occasionally I want to exclude a directory (usually
"drivers/"), and it all works fin
17 matches
Mail list logo