Beat Bolli <dev+git@xxxxxxxxx> writes:
> On 06.09.20 23:59, Junio C Hamano wrote:
>> Denton Liu <liu.denton@xxxxxxxxx> writes:
>>
>>> Hmm, I'm not sure how I feel about being able to override formats other
>>> than "reference".
>>
>> Is the idea to introduce a parallel namespace to pretty.<name>? I
>> am not sure why that is a good idea than, say a single variable that
>> says "to me, pretty.<name> would override even the built-in names".
>>
>> I am not sure how I feel about being able to override built-in
>> formats in the first place, though.
>>
>> After all, pretty.<name> were introduced so that user-defined ones
>> can be invoked with an equal ease as the built-in ones, but
>> overriding common understanding among the users of the tool is a
>> different story.
>
> I gave a reason for the reference format, at least.
>
> Would you be fine with a patch that just allows to override the
> reference format (for the stated reasons)?
Your "reason" read pretty much the same as "I want reference to do
something else", but that leads to "depending on the configuration,
even built-in names that are well known to all Git users behave
differently---the users lose common reference (no pun intended)".
Also I am not sure how your reason applies specifically to the
reference format. It would be widely applicable to other formats
like 'short' and 'oneline' in that depending on projects' and
personal preference, people may want "something like X but not
exactly X" for all the built-in formats.
IOW I still do not see why your "stated reasons" justify overriding
any built-in format, and/or overriding only the reference format. I
can understand (but not necessarily agree with) the position "We'll
let any built-in format to be overridden", but I do not see what
makes "reference" so special. Even though I think it would confuse
the users to make any built-in format overridable and therefore I do
not think it is such a good idea, if we were to allow it, I do not
see any point in limiting the damage only to the reference format.
Finally, a non-built-in name to express the format specific to a
project can already be defined and used pretty easily; e.g. the
"pretty.kernel" format may say %h ("%s") and can be used like
$ git show -s --pretty=kernel HEAD
with the same ease as the 'reference' format.
$ git show -s --pretty=reference HEAD
So, I dunno.
