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
Attachment:
signature.asc
Description: PGP signature
