Rafael Ascensão writes:
> I agree that describe should receive the "normalize" treatment. However,
> and following the same reasoning, why should describe users adopt the
> rules imposed by --glob? I could argue they're also used to the way it
> works now.
>
> That being said, the suggestion I me
On 07/11/17 00:18, Junio C Hamano wrote:
> Jacob Keller writes:
>
> I would have to say that the describe's one is wrong if it does not
> match what for_each_glob_ref() does for the log family of commands'
> "--branches=" etc. describe.c::get_name() uses positive
> and negative patterns, just li
Jacob Keller writes:
> On November 3, 2017 8:49:15 PM PDT, Junio C Hamano wrote:
>>Rafael Ascensão writes:
>>
>>Why should this be a special case that burdens users to remember one
>>more rule? Wouldn't users find "--decorate-refs=refs/tags" useful
>>and it woulld be shorter and nicer than hav
On November 3, 2017 8:49:15 PM PDT, Junio C Hamano wrote:
>Rafael Ascensão writes:
>
>Why should this be a special case that burdens users to remember one
>more rule? Wouldn't users find "--decorate-refs=refs/tags" useful
>and it woulld be shorter and nicer than having to say "refs/tags/*"?
>
On 11/05/2017 07:17 AM, Junio C Hamano wrote:
> Junio C Hamano writes:
>> Rafael Ascensão writes:
>> ...
>>> Because changing the default behavior of that function has
>>> implications on multiple commands which I think shouldn't change. But
>>> at the same time, would be nice to have the logic t
Rafael Ascensão writes:
> Would checking the output of ref_exists() make sense here?
> By that I mean, only add a trailing '/*' if the ref doesn't exist.
I do not think it would hurt, but it is not immediately obvious if
the benefit of doing so outweighs the cost of having to make an
extra call
Would checking the output of ref_exists() make sense here?
By that I mean, only add a trailing '/*' if the ref doesn't exist.
Unless I am missing something obvious this would allow us to keep both
shortcuts and exact patterns.
Junio C Hamano writes:
> Rafael Ascensão writes:
> ...
>> Because changing the default behavior of that function has
>> implications on multiple commands which I think shouldn't change. But
>> at the same time, would be nice to have the logic that deals with
>> glob-ref patterns all in one place.
Rafael Ascensão writes:
>>> The pattern follows similar rules as `--glob` except it doesn't assume a
>>> trailing '/*' if glob characters are missing.
>>
>> Why should this be a special case that burdens users to remember one
>> more rule? Wouldn't users find "--decorate-refs=refs/tags" useful
>
On 04/11/17 03:49, Junio C Hamano wrote:
Rafael Ascensão writes:
Using `--exclude=` can help mitigate that verboseness by
removing unnecessary 'branches' from the output. However, if the tip of
an excluded ref points to an ancestor of a non-excluded ref, git will
decorate it regardless.
Is t
Rafael Ascensão writes:
> When `log --decorate` is used, git will decorate commits with all
> available refs. While in most cases this the desired effect, under some
> conditions it can lead to excessively verbose output.
Correct.
> Using `--exclude=` can help mitigate that verboseness by
> rem
11 matches
Mail list logo