Re: Proposal: server-advertised config options

["Drew DeVault" <sir@cmpwn.com>]

On Mon Sep 7, 2020 at 2:51 PM EDT, Junio C Hamano wrote:
> Assuming I am among the guys (do you solicit opinions from gals, by
> the way?), here are a few unconnected random thoughts.

Guys is gender netural where I'm from, of course guys and gals and
anyone else are invited to comment :)

> I do not want to see this as a "server" thing. All the examples are
> "per project preference" and I do agree it would be nice to have a
> standardised way for projects to communicate their preference to
> their participants. Regardless of the hosting site I clone and
> fetch my project from, I'd want to see it communicated consistently
> to them.

The server I have in mind (git.sr.ht) is a little bit different in that
most of those examples I gave would be configured automatically on the
server side. My server software knows where your mailing list is, for
example. My goal is to try and make this as hands-off and "it just
works" as possible.

> In addition to your examples of "per project preference", there are
> projects' coding style guides, etc., that we do not enforce as git
> config at all, e.g. how wide your editors TAB and single level of
> indentation should be. It will unnecessarily narrow your view to
> assume that the kind of "per project preference" you convey from the
> project to its participants need to be the Git configuration and
> nothing else.

I think there's a difference between preferences regarding the contents
of the repository (e.g. style guide), and preferences regarding the
administration and usage of the repository itself (e.g. this feature I'm
proposing). I think the argument for integration with git is much
stronger for the latter.

> All of the above leads to a design to have a common convention
> widely shared among projects to express project preferences over
> different kind of tools, among which Git is one of them, and store
> it in a known location in the projects' trees. Most importantly,
> there must not be any Git protocol extension for doing this kind of
> thing.

Storing a file in your project tree to handle this configuration would
eliminate the "hands off" feature I was aiming for. We also have a
policy which forbids our software from making any automated changes to
the contents of your git repository - we just don't consider it
appropriate in the domain of our server software's responsibilities.

Some sort of common config file for this purpose, in-tree, would perhaps
be useful, but it would remove a lot of the value-add that I'm seeking
to provide. I already posess most of the necessary information
server-side and I can offer it to clients without any explicit
involvement from the project maintainers.

Also, the conventions for tooling-related files in-tree like this is
currently very disorganized within the ecosystem. Between .editorconfig,
.gitattributes, .github/funding.yml, a dozen CI systems, and who knows
what else, there's no common consensus on where to put files like this
or what they should look like. I think that securing consensus for this
would involve reaching out to these projects, and the scope of that
effort and the necessary follow-up developments and compatibility
planning on behalf of these projects would be...  astonishingly large.

And, ultimately, even with a common configuration, we'd end up having to
add vendor-specific extensions, for example to support the example of
push options given in the initial mail.

So, in summary, based on your suggestions this proposal could grow
10x-100x in scope and lose no small degree of the desired utility. Maybe
yours is a worthwhile idea, but it poorly solves the particular problem
I set out to solve and I lack the time/motivation to work on that
approach.