On 2020-09-07 at 19:23:15, Drew DeVault wrote:
> On Mon Sep 7, 2020 at 2:51 PM EDT, Junio C Hamano wrote:
> > 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.

The Git security model doesn't permit untrusted config options, so I
think it's risky to add support for config options from the server
side.  We need to consider not only advanced users who are going to be
able to make a good decision here, but novice users who are struggling
to understand how Git works and are prone to social engineering.  Just
because your server is not malicious does not mean that others aren't.

In addition, if I'm cloning a repository just to build it, I don't want
to be prompted to set those configuration options at all.  My experience
in Git hosting is that clones and fetches far, far outnumber pushes, so
adding a prompting feature adds a bunch of impediment with little gain
for the vast majority of users.

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

That doesn't mean you can't provide a downloadable shell script that
people could check into their repositories to configure this for the
user.  That's the typical way that projects that use standardized hooks
work, for example, and it lets the user decide whether they want to
configure these things (by running the script) or not (by not running
it).  Users who are not interested in becoming contributors need not
ever be bothered with it at all.

It doesn't automatically "just work", but it also lets projects decide
for themselves what their settings should be.  Just because a site
offers, say, mailing lists, doesn't mean that folks will want to use
those mailing lists.  For example, the Go language repository is hosted
on GitHub, but uses Gerrit for code review, not GitHub pull requests.

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

You can try to standardize all repository dotfiles, or you can just
provide a configuration file and documentation and let people adopt it
as you go, which is how most of these work.  If your design is
desirable, people will adopt it and spread it across projects.
-- 
brian m. carlson: Houston, Texas, US