Re: The git spring cleanup challenge

[Felipe Contreras <felipe.contreras@gmail.com>]

Ævar Arnfjörð Bjarmason wrote:
> 
> 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@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.

As I explaind the problem is that the build infraestructure is
completely unprepared to install files in /usr/share.

Go ahead and try to add a simple text file to the distribution.

Are you going to put it under /usr/share/git-core? Where are you going
to add it in the git tree? What target is going to install it?

> 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.

I know, I do see value in this approach, which is why I tried. But when
I saw I was making more changes to the Makefile than the code I decided
to stop.

Moreover, it makes little sense to implement this perfectly if Junio is
simply going to reject it all.

Maybe once we have the "extra" directory it would be more straightforward.

-- 
Felipe Contreras