Re: Proposal: server-advertised config options

From: Drew DeVault <sir@cmpwn.com>
Date: Sep 7, 2020, 19:23 UTC
Message-ID: <C5HDRLX7ZPR5.1TFS72T7PBXSJ@homura>
In-Reply-To: <xmqqimcp1kvf.fsf@gitster.c.googlers.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 :)

Show 6 quoted lines

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

Show 7 quoted lines

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

Show 6 quoted lines

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