On Fri, Jul 02 2021, Felipe Contreras wrote: > Æ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@xxxxxxxxx/ 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.
