From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: "Matthieu Moy" <Matthieu.Moy@grenoble-inp.fr>,
"Rasmus Villemoes" <rv@rasmusvillemoes.dk>,
"Jakub Narębski" <jnareb@gmail.com>,
"Tanay Abhra" <tanayabh@gmail.com>,
git@vger.kernel.org
Subject: Re: [PATCH/RFC 0/5] add "unset.variable" for unsetting previously set variables
Date: Mon, 13 Oct 2014 11:21:50 -0700 [thread overview]
Message-ID: <xmqqh9z74ypt.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <20141010081107.GA8355@peff.net> (Jeff King's message of "Fri, 10 Oct 2014 04:11:07 -0400")
Jeff King <peff@peff.net> writes:
> ... Which makes me wonder if safe-include is really helping that
> much versus a project shipping a shell script that munges the repository
> config. The latter is less safe (you are, after all, running code, but
> you would at least have the chance to examine it), but is way more
> flexible. And the safety is comparable to running "make" on a cloned
> project.
>
> I dunno. I do not have anything against the safe-include idea, but each
> time it comes up, I think we are often left guessing about exactly which
> config options projects would want to set, and to what values.
I tend to agree. Every time somebody says "a project wants to give
its participants suggested settings", we seem to tell them to ship
an instruction to their participants, either in BUILDING or setup.sh
or whatever. It certainly is simpler and more flexible.
The only real difference it might make is an attempt to push to an
unattended place and automatically making the changes to take effect,
aka "push to deploy", which is not what we encourage anyway, so...
prev parent reply other threads:[~2014-10-13 18:22 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-02 13:24 [PATCH/RFC 0/5] add "unset.variable" for unsetting previously set variables Tanay Abhra
2014-10-02 13:24 ` [PATCH/RFC 1/5] config.c : move configset_iter() to an appropriate position Tanay Abhra
2014-10-02 13:24 ` [PATCH/RFC 2/5] make git_config_with_options() to use a configset Tanay Abhra
2014-10-02 13:24 ` [PATCH/RFC 3/5] add "unset.variable" for unsetting previously set variables Tanay Abhra
2014-10-02 13:24 ` [PATCH/RFC 4/5] document the new "unset.variable" variable Tanay Abhra
2014-10-02 13:24 ` [PATCH/RFC 5/5] add tests for checking the behaviour of "unset.variable" Tanay Abhra
2014-10-02 20:09 ` Junio C Hamano
2014-10-02 20:18 ` Tanay Abhra
2014-10-02 20:23 ` Junio C Hamano
2014-10-02 20:35 ` Tanay Abhra
2014-10-02 23:38 ` Junio C Hamano
2014-10-03 7:01 ` Matthieu Moy
2014-10-03 18:25 ` Junio C Hamano
2014-10-03 18:48 ` Junio C Hamano
2014-10-03 19:49 ` Matthieu Moy
2014-10-03 20:12 ` Junio C Hamano
2014-10-06 18:59 ` Tanay Abhra
2014-10-06 19:28 ` Junio C Hamano
2014-10-06 19:43 ` Tanay Abhra
2014-10-02 19:29 ` [PATCH/RFC 0/5] add "unset.variable" for unsetting previously set variables Junio C Hamano
2014-10-02 20:41 ` Jeff King
2014-10-02 19:58 ` Junio C Hamano
2014-10-07 11:17 ` Jakub Narębski
2014-10-07 16:44 ` Junio C Hamano
2014-10-08 5:46 ` Matthieu Moy
2014-10-08 17:14 ` Junio C Hamano
2014-10-08 18:37 ` Matthieu Moy
2014-10-08 19:52 ` Junio C Hamano
2014-10-10 8:11 ` Jeff King
2014-10-13 18:21 ` Junio C Hamano [this message]
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqh9z74ypt.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=Matthieu.Moy@grenoble-inp.fr \
--cc=git@vger.kernel.org \
--cc=jnareb@gmail.com \
--cc=peff@peff.net \
--cc=rv@rasmusvillemoes.dk \
--cc=tanayabh@gmail.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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.