Re: The git spring cleanup challenge

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Jul 2, 2021, 11:43 UTC
Message-ID: <87zgv59bm8.fsf@evledraar.gmail.com>
In-Reply-To: <60dee69fb7cc7_2964b208fb@natae.notmuch>

On Fri, Jul 02 2021, Felipe Contreras wrote:

Show 42 quoted lines

> Ævar Arnfjörð Bjarmason wrote:
>> On Thu, Jun 03 2021, Felipe Contreras wrote:
>> > Ævar Arnfjörð Bjarmason wrote:
>
>> >> We could then just extend the include syntax rather easily to include
>> >> "libraries", which would be like the current include.path, but would
>> >> understand a library:: prefix (better name bikeshedding welcome). We'd
>> >> then just ship these in /usr/share/git-core/config/includes or whatever,
>> >> e.g. /usr/share/git-core/config/includes/aliases/svn-like.cfg
>> >
>> > I wouldn't be against some some suggested defaults, but *in addition* to
>> > some hardcoded default aliases that are documented.
>> 
>> I'm talking about in terms of the flexibility of implementation of
>> on-by-default defaults. We could implement it as I suggested and then
>> just have a core.defaultIncludes, which would by default be set to
>> git::aliases/svn-like.cfg or whatever, i.e. equivalent to:
>> 
>>     [core]
>>     defaultIncludes = "git::default.cfg"
>> 
>> Which itself would include a
>> /usr/share/git-core/config/includes/default.cfg which would do:
>
> I really gave this a try, but the problem is that git doesn't even have
> a stardard location to install shared files.
>
> I started with $sharedir, but that's not git-specific. Then I added
> $gitsharedir which required a bunch of changes to the Makefile, and
> eventually I decided against it.
>
> We don't have standard location for shared files. Period.
>
>> In a way this is total bikeshedding, I just think it's worth doing it
>> this way up-front.
>
> Yes, maybe so, but git infraestructure is completely unprepared for that
> (at this point).
>
> So I just decied to hard-code them [1]
>
> [1] https://lore.kernel.org/git/20210702100506.1422429-1-felipe.contreras@gmail.com/

FWIW I only saw this reply after I replied in that thread ... referencing this one.

I haven't tried, but I'd think it wouldn't be a big change. You're injecting alias.* config directly, you could just inject an include.path=* in the relevant part of the config machinery instead.

We'd need a new verb like gitdir:* and onbranch:*, maybe system:* or git:*, we'd then search system:foo.cfg for those relative to our libexec or /usr/share data, e.g. /usr/lib/git-core/config/foo.cfg

We could then carry those in includes/* in the git.git repo, and to address the "let's make sure they're there" have a trivial build step like the command-list.h to build those into a C object. I.e. dog-food on our own build process and run `git config -f <file> -l -z` for each one, munge that and spew it into a *.c file. I.e. include/aliases/svn-like.cfg or whatever.

Then when we can't find a system:* (or whatever it's called) handle_path_include() we'd consult that list of fallbacks.

I'm not saying it's trivial, just that I think in practice building consensus for a "one blessed list of hardcoded aliases" is going to be a very tough sell, and making it optional/configurable/pluggable might make that sell a lot easier.