git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Taylor Blau <me@ttaylorr.com>
To: Zeger-Jan van de Weg <git@zjvandeweg.nl>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 0/1] git-config --add allows values from stdin
Date: Sat, 21 Sep 2019 23:11:28 -0400	[thread overview]
Message-ID: <20190922031128.GA76333@syl.lan> (raw)
In-Reply-To: <20190917133135.190145-1-git@zjvandeweg.nl>

Hi ZJ,

On Tue, Sep 17, 2019 at 03:31:34PM +0200, Zeger-Jan van de Weg wrote:
> When adding or updating configuration values using git-config, the
> values could all be observed by different processes as these are passed
> as arguments. In some environments all commands executed are also all
> logged. When the value contains secrets, this is a side effect that
> would be great to avoid. At GitLab we use Rugged/libgit2 to circumvent
> this property[1].
>
> The following patch allows a value to be set through stdin when the user
> passes a `--stdin` flag.

Interesting. I had thought some time ago about making an interactive
line-oriented 'mode' for using 'git-config(1)', which would allow
callers to add/delete/fetch multiple variables using only a single
process.

This would satisfy a more general use-case than yours: particularly my
idea was grown out of wanting to specify or read many configuration
entries at once when using a tool built around Git, such as Git LFS.

I had not considered tying '--stdin' to the '--add' (implicit or not)
mode of 'git-config(1)'. It is an interesting idea to be sure.

On the one hand, it lends itself to other modes, such as '--get'
combined with '--stdin', or '--unset' in the same fashion. One could
imagine that each of these would take either a key/value-pair (in the
case of '--add') or a set of key(s) (in the remaining cases). The most
desirable aspect is that this would allow for a clear path to this
series being picked up.

On the other hand, tying '--stdin' to a particular mode of using 'git
conifg' seems overly restrictive to me. If I am building a tool that
wants to fetch some values in the configuration, and then add/unset
others based on the results using only a single process, I don't think
that a mode-based '--stdin' flag gets the job done.

One happy medium that comes to mind is a new '--interactive' mode, which
implies '--stdin' and would allow the above use-case, e.g.:

  $ git config --interactive <<\EOF
  get core.myval
  set core.foo bar
  unset core.baz
  EOF

(An off-topic note is that it would be interesting to allow more
fanciful options than 'get', e.g., 'get' with a '--type' specifier, or
some such).

I'm not sure if anyone actually wants to use 'git-config(1)' in this
way, but I figured that I would at least share some things that I was
thinking about when initially considering this proposal.

> [1]: https://gitlab.com/gitlab-org/gitaly/blob/8ab5bd595984678838f3f09a96798b149e68a939/ruby/lib/gitlab/git/http_auth.rb#L14-15
>
> Zeger-Jan van de Weg (1):
>   Git config allows value setting from stdin
>
>  Documentation/git-config.txt |  5 ++++-
>  builtin/config.c             | 23 +++++++++++++++++++++--
>  t/t1300-config.sh            | 11 +++++++++++
>  3 files changed, 36 insertions(+), 3 deletions(-)
>
> --
> 2.23.0
>

Thanks,
Taylor

  parent reply	other threads:[~2019-09-22  3:11 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-17 13:31 [PATCH 0/1] git-config --add allows values from stdin Zeger-Jan van de Weg
2019-09-17 13:31 ` [PATCH 1/1] Git config allows value setting " Zeger-Jan van de Weg
2019-09-17 16:59   ` Junio C Hamano
2019-09-22  3:11 ` Taylor Blau [this message]
2019-09-23  9:46   ` [PATCH 0/1] git-config --add allows values " Phillip Wood
2019-09-23 11:45   ` SZEDER Gábor

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=20190922031128.GA76333@syl.lan \
    --to=me@ttaylorr.com \
    --cc=git@vger.kernel.org \
    --cc=git@zjvandeweg.nl \
    /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 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 NNTP newsgroup(s).