From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-3.6 required=3.0 tests=AWL,BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by dcvr.yhbt.net (Postfix) with ESMTP id 886871F66E for ; Mon, 7 Sep 2020 17:03:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731006AbgIGRDP (ORCPT ); Mon, 7 Sep 2020 13:03:15 -0400 Received: from mail.cmpwn.com ([45.56.77.53]:47116 "EHLO mail.cmpwn.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730892AbgIGRDB (ORCPT ); Mon, 7 Sep 2020 13:03:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cmpwn.com; s=cmpwn; t=1599498175; bh=czfHeRlz4v+vPiHEG0NCPNVZ/gP+s6I9+VZ8kZ0SrLg=; h=Subject:From:To:Date; b=fTljxiICBGNuCyEfiqGF7tARGi6UlOiuDAQYE6tIttPrhk8OGbM9iVY9jW9PtxDEI lmwS2d77HCMFqcEQhHrORDa3PjBy3nyodEQTaUFXEUsCKBXS60IBFUMsJ6WtfNebmj mmY4cLpbbvGzfc+KNINg94+Lev/hlT96DFOH7yfc= Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Subject: Proposal: server-advertised config options From: "Drew DeVault" To: Date: Mon, 07 Sep 2020 12:52:12 -0400 Message-Id: Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org 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?