Re: Enhancing --show-function and --function-context in default configurations

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Aug 02, 2021 at 10:45:25AM +0200, Ævar Arnfjörð Bjarmason wrote:

> I would like to see us have a setting to turn these on by default, but
> think it would be better to make that a diff.* config setting to put
> into ~/.gitconfig, i.e. we'd extend git itself to know about a list of
> extensions for the given userdiff drivers, and use them when rendering
> diffs.

A long time ago we discussed doing this. The relevant thread is:

  https://lore.kernel.org/git/20111216110000.GA15676@xxxxxxxxxxxxxxxxxxxxx/

which references a few others:

  https://lore.kernel.org/git/4E569F10.8060808@xxxxxxxxxxx/

  https://lore.kernel.org/git/4E6E928A.6080003@xxxxxxxxxxxxxx/

>From my re-read of the threads, it seemed like people were mostly on
board with the idea, but:

  - there was some question about a few of the more obscure extensions
    (e.g., '.m' as objective-c versus matlab). Obviously we could drop
    any contentious ones, though I do wonder if this is simply opening
    up a can of worms where people will fight about what ought to go
    into the "official" list.

  - there was some question over whether some of our builtin funcname
    regexps were actually worse than the default behavior (especially
    the "cpp" one). In response we started using .gitattributes more
    heavily within git.git itself, and we've seen quite a few
    improvements in the intervening decade.

    So hopefully there is no reason anybody would _not_ want the
    content-specific driver to kick in, assuming that the extension
    mapping is accurate. There should be no security risk or anything
    like that, since we'd already respect such a mapping from an
    untrusted repository via its .gitattributes file.

It looks like Junio picked up the patch at one point, but it got bumped
to the next release cycle. It was marked as "expecting a re-roll" until
finally getting discarded in Oct 2011; you can see the progression
by searching for "jk/default-attr":

  https://lore.kernel.org/git/?q=jk%2Fdefault-attr

Then in Dec 2011 I posted that re-roll (the top link I gave above), and
it looks like it never got picked up.  I don't see any conclusions
either way in the thread, so I think it just kind of died out due to
lack of anybody pushing it forward (and I don't remember making a
decision either way on that; it may have been the "can of worms" thing
above scaring me off).

-Peff



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux