Re: [PATCH v1 2/2] log: add option to choose which refs to decorate

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

Re: [PATCH v1 2/2] log: add option to choose which refs to decorate

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

Re: [PATCH v1 2/2] log: add option to choose which refs to decorate

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

Re: [PATCH v1 2/2] log: add option to choose which refs to decorate

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

Re: [PATCH v1 2/2] log: add option to choose which refs to decorate

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

Re: [PATCH v1 2/2] log: add option to choose which refs to decorate

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

Re: [PATCH v1 2/2] log: add option to choose which refs to decorate

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.

Re: [PATCH v1 2/2] log: add option to choose which refs to decorate

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

Re: [PATCH v1 2/2] log: add option to choose which refs to decorate

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

Re: [PATCH v1 2/2] log: add option to choose which refs to decorate

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

Re: [PATCH v1 2/2] log: add option to choose which refs to decorate

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

[PATCH v1 2/2] log: add option to choose which refs to decorate

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. Using `--exclude=` can help mitigate that verboseness by removing unnecessary 'branches' from the output.