Re: The git spring cleanup challenge

Ævar Arnfjörð Bjarmason wrote:

On Fri, Jul 02 2021, Felipe Contreras wrote:

quoted

Ævar Arnfjörð Bjarmason wrote:

quoted

On Thu, Jun 03 2021, Felipe Contreras wrote:

quoted

Ævar Arnfjörð Bjarmason wrote:

quoted

quoted

quoted

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.

quoted

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/ (local)

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