appending a pattern to the default "diff.cpp.xfuncname"

appending a pattern to the default "diff.cpp.xfuncname"

[Laszlo Ersek]

Hi,

I've used diff.<TYPE>.xfuncname with great success for file <TYPE>s that
I defined myself. However, now I would like to append an extra pattern
to the TYPE=cpp case (for which git has builtin patterns). Is there an
easy way to do this?

I figured I could open-code the builtin patterns from "userdiff.c", and
then append my new pattern to those, but it looks kinda gross :)

Thanks!
Laszlo

Re: appending a pattern to the default "diff.cpp.xfuncname"

[Jeff King]

On Wed, Aug 03, 2016 at 12:16:14PM +0200, Laszlo Ersek wrote:

> I've used diff.<TYPE>.xfuncname with great success for file <TYPE>s that
> I defined myself. However, now I would like to append an extra pattern
> to the TYPE=cpp case (for which git has builtin patterns). Is there an
> easy way to do this?
> 
> I figured I could open-code the builtin patterns from "userdiff.c", and
> then append my new pattern to those, but it looks kinda gross :)

Unfortunately, no, the config system has no notion of "append to this
value". So you are stuck with extracting the builtin value (which
annoyingly, you cannot even get without looking at the source code!),
and repeating it in your config file.

-Peff

Re: appending a pattern to the default "diff.cpp.xfuncname"

[Laszlo Ersek]

On 08/03/16 20:02, Jeff King wrote:
> On Wed, Aug 03, 2016 at 12:16:14PM +0200, Laszlo Ersek wrote:
> 
>> I've used diff.<TYPE>.xfuncname with great success for file <TYPE>s that
>> I defined myself. However, now I would like to append an extra pattern
>> to the TYPE=cpp case (for which git has builtin patterns). Is there an
>> easy way to do this?
>>
>> I figured I could open-code the builtin patterns from "userdiff.c", and
>> then append my new pattern to those, but it looks kinda gross :)
> 
> Unfortunately, no, the config system has no notion of "append to this
> value". So you are stuck with extracting the builtin value (which
> annoyingly, you cannot even get without looking at the source code!),
> and repeating it in your config file.

Thank you for confirming!
Laszlo

Re: appending a pattern to the default "diff.cpp.xfuncname"

[Jakub Narębski]

W dniu 03.08.2016 o 20:02, Jeff King pisze:
> On Wed, Aug 03, 2016 at 12:16:14PM +0200, Laszlo Ersek wrote:
> 
>> I've used diff.<TYPE>.xfuncname with great success for file <TYPE>s that
>> I defined myself. However, now I would like to append an extra pattern
>> to the TYPE=cpp case (for which git has builtin patterns). Is there an
>> easy way to do this?
>>
>> I figured I could open-code the builtin patterns from "userdiff.c", and
>> then append my new pattern to those, but it looks kinda gross :)
> 
> Unfortunately, no, the config system has no notion of "append to this
> value". 

And I think adding such capability would not be easy.  Well, perhaps
we could support '+=' in addition to '='?

>         So you are stuck with extracting the builtin value (which
> annoyingly, you cannot even get without looking at the source code!),
> and repeating it in your config file.

I wonder if `git var -l` could provide all default values :-P

-- 
Jakub Narębski

Re: appending a pattern to the default "diff.cpp.xfuncname"

[Jeff King]

On Wed, Aug 03, 2016 at 08:34:28PM +0200, Jakub Narębski wrote:

> > Unfortunately, no, the config system has no notion of "append to this
> > value". 
> 
> And I think adding such capability would not be easy.  Well, perhaps
> we could support '+=' in addition to '='?

We could, but it would be an incompatible syntactic change, which we've
so far managed to avoid.

> >         So you are stuck with extracting the builtin value (which
> > annoyingly, you cannot even get without looking at the source code!),
> > and repeating it in your config file.
> 
> I wonder if `git var -l` could provide all default values :-P

I had a similar thought, but it's quite difficult because of the way
that default values are structured in git. Most code uses initialization
of C variables (including structs) to set up default values, and then
overrides them if it sees relevant config.

So there is no central code to ask "what is the value of X if I don't
provide any config"? It literally requires dumping a bunch of variables.

One thing we could do is move all of those defaults into an "internal"
config that is baked into the executable, and then parse that at the
lowest-priority level of config. And then "git config --list
--show-origin" could presumably just dump it.

But that would mean parsing it at run-time in every program (which is
probably not _that_ much overhead, but does feel wrong). I'd also
suspect there are a few cases whose defaults are expressed in code,
rather than as single variable assignments, and couldn't be represented
as config at all.

-Peff