Re: [PATCH 5/5] pathspec: record labels

Stefan Beller writes: > "Path '%s': Ignoring label set to false; This may behave > differently in future versions of Git." I agree that mentioning "ignoring" is good enough. I think our recent messages begin with lowercase, though. -- To unsubscribe from this list:

Re: [PATCH 5/5] pathspec: record labels

On Mon, May 16, 2016 at 12:08 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> "... but for now Git treats it as if it is not set at all" is a valuable >> information to the user, still? > > Not at all. "What you are using is wrong and there is no

Re: [PATCH 5/5] pathspec: record labels

Stefan Beller writes: > "... but for now Git treats it as if it is not set at all" is a valuable > information to the user, still? Not at all. "What you are using is wrong and there is no guarantee what behaviour you would get" is the message we need to convey. -- To

Re: [PATCH 5/5] pathspec: record labels

On Mon, May 16, 2016 at 11:52 AM, Junio C Hamano wrote: > Stefan Beller writes: > >> So "warn and ignore" for data from .gitattributes and die for >> commandline arguments? That makes sense. > > Yes. > > On the "command line" front, because we may want to

Re: [PATCH 5/5] pathspec: record labels

Stefan Beller writes: > So "warn and ignore" for data from .gitattributes and die for > commandline arguments? That makes sense. Yes. On the "command line" front, because we may want to give different meanings to these two entries in the future:

Re: [PATCH 5/5] pathspec: record labels

Stefan Beller writes: >> I am NOT suggesting to make this enhancement in the prototype to >> allow us experiment with submodule selection use case, but this is >> an obvious place to allow >> >> :(label=A B):(label=C D) >> >> to mean ((A & B) | (C & D)) by making

Re: [PATCH 5/5] pathspec: record labels

> I am NOT suggesting to make this enhancement in the prototype to > allow us experiment with submodule selection use case, but this is > an obvious place to allow > > :(label=A B):(label=C D) > > to mean ((A & B) | (C & D)) by making item->labels an array of set > of labels. This is what

Re: [PATCH 5/5] pathspec: record labels

On Mon, May 16, 2016 at 10:38 AM, Junio C Hamano wrote: > Stefan Beller writes: > >>> Let's avoid "are meant to", which is merely to give you an excuse to >>> say "it was meant to ... but the implementation did not quite achieve >>> that goal". >>> >>>

Re: [PATCH 5/5] pathspec: record labels

Stefan Beller writes: >> Let's avoid "are meant to", which is merely to give you an excuse to >> say "it was meant to ... but the implementation did not quite achieve >> that goal". >> >> The "label" attribute can be attached to paths, and the pathspec >> mechanism is

Re: [PATCH 5/5] pathspec: record labels

On Sat, May 14, 2016 at 12:23 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> Labels were originally designed to manage large amount of >> submodules, the discussion steered this in a more general >> direction, such that other files can be labeled as

Re: [PATCH 5/5] pathspec: record labels

Stefan Beller writes: > Labels were originally designed to manage large amount of > submodules, the discussion steered this in a more general > direction, such that other files can be labeled as well. s/other files/any path/. > Labels are meant to describe arbitrary set of

[PATCH 5/5] pathspec: record labels

Labels were originally designed to manage large amount of submodules, the discussion steered this in a more general direction, such that other files can be labeled as well. Labels are meant to describe arbitrary set of files, which is not described via the tree layout. Signed-off-by: Stefan