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: send the line "unsubscri
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 guarantee
> what behaviour you would get"
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 unsubscribe from this list:
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 give different
> meanings to these two en
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:
:(label=-doc)Documentation/
:(la
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 item->labels an array of
> 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
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".
>>>
>>> The "label" attribute can be attached to
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 extended via the new
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 well.
>
> s/other files/any path/.
>
>>
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 files, which
> is not
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 Belle
12 matches
Mail list logo
