git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Drew DeVault" <sir@cmpwn.com>
Cc: <git@vger.kernel.org>
Subject: Re: Proposal: server-advertised config options
Date: Mon, 07 Sep 2020 11:51:00 -0700	[thread overview]
Message-ID: <xmqqimcp1kvf.fsf@gitster.c.googlers.com> (raw)
In-Reply-To: <C5HAJYI9RDPU.1CPN4E1JCQCAQ@homura> (Drew DeVault's message of "Mon, 07 Sep 2020 12:52:12 -0400")

"Drew DeVault" <sir@cmpwn.com> writes:

> The basic idea is that the server could advertise some config options
> which it recommends the client sets for a given repo after a fetch. Some
> possible use-cases for this feature include setting:
>
> - format.subjectPrefix to 'PATCH my-project'
> - sendemail.to to the mailing list address
> - push.pushOption to recommended push options
>
> Upon cloning, each recommended config option would be displayed to the
> user, and they would be prompted ([Y/n]) to agree to set that value in
> the config file for that repository. Additionally, there would be a
> config option which white-lists a list of config options which are
> automatically agreed to without prompting, and each config option would
> have one of the following states:
>
> - accept-silent: set the option without printing a message
> - accept-verbose: set the option and display a message
> - prompt: prompt the user to set this config option
> - reject-silent: silently refuse to set this config option
> - reject-verbose: refuse to set this config option and display a message
>
> We would default to reject-verbose for all unknown config options and
> include a set of defaults which specifies the appropriate trust level
> for various useful benign options (such as the examples above).
>
> The implementation would involve advertising config-advertisement in the
> fetch protocol. Both the client and server would have to agree to use
> it. If the server supports it but the client does not (in the case of an
> old client), it could fall back to printing the list of recommended
> options to stderr.
>
> To choose which config options to advertise, a new option would be
> introduced (uploadpack.advertiseOptions) for example, which has a list
> of .git/config options from the remote repository to forward to the
> client.
>
> This would be a lot of work so I'd like to float it for discussion
> before getting started. What do you guys think?

Assuming I am among the guys (do you solicit opinions from gals, by
the way?), here are a few unconnected random thoughts.

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.

Which means that it must not be a patch to the "server" component to
what responds to your "git fetch" and "git clone" (i.e. upload-pack)
as some hosting sites do not even use upload-pack.

Also, I do not want to see this as a "git" thing and I mean it in
two ways.  

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.

And this should not be a "git the SCM" thing.  If you download and
extract a release tarball and write a patch on top of it, you should
be able to learn what the project convention of what the "[PATCH]"
prefix looks like and what the mailing list address is, even though
you did not clone with "git".

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.  

Don't limit the user's choice in either of these two ways.  The
preferences for tools other than Git should be sharable with the
same ease as preference for Git, and the preference should be
sharable with the same ease to those who use Git and those who
don't.

Perhaps have a .project-preference/ directory at the root level of
the project tree, talk with other SCM vendors and editor vendors to
design what kind of information are recorded in that directory and
how, and write a script to work on that to map the project
preference information to git configuration while other SCM vendors
and editor vendors write their scripts to help their users to map
the project preference information to the configuration files that
their tools use.  Then you can either write a wrapper around "git
clone" to first run "git clone" and then run these scripts you
prepare to process the contents of the .project-preference
directory, or perhaps trigger these scripts from the post-clone hook.

  parent reply	other threads:[~2020-09-07 18:51 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-07 16:52 Proposal: server-advertised config options Drew DeVault
2020-09-07 18:49 ` Christian Couder
2020-09-07 18:49   ` Drew DeVault
2020-09-07 18:51 ` Junio C Hamano [this message]
2020-09-07 19:23   ` Drew DeVault
2020-09-07 20:52     ` brian m. carlson
2020-09-08 14:14       ` Drew DeVault
2020-09-10  1:45         ` brian m. carlson
2020-09-10  4:27           ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqimcp1kvf.fsf@gitster.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=sir@cmpwn.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).