From: Jonathan Nieder <jrnieder@gmail.com>
To: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Cc: Morgan McClure <mcclure.morgan@gmail.com>, git@vger.kernel.org
Subject: Re: Feature Request: Support logic or shell execution to control values in .gitconfig
Date: Sat, 10 Aug 2013 13:19:32 -0700 [thread overview]
Message-ID: <20130810201932.GA3031@elie.Belkin> (raw)
In-Reply-To: <vpq1u64dx63.fsf@anie.imag.fr>
Matthieu Moy wrote:
> That would mean executing SOMETEXTTOEXECUTE each time the config file is
> read. This raises two issues:
>
> * A security issue, as SOMETEXTTOEXECUTE could also be something
> dangerous. It would not be much worse than the current situation (if
> your config file is not trusted, then an attacker could put malicious
> code in core.editor for example), but still increase the security
> risk (as any command reading the config may trigger execution).
I don't think the security issue is too bad. As you say, the
combination of control over core.pager and pager.config is already
pretty dangerous.
> * A performance issue with the current git implementation, as the config
> file may be read many time for a single git execution.
This issue is harder.
>> Is this a feature others could get behind?
>
> I think it's unlikely that this ever be implemented. What I suggest
> instead is to edit/track/share template configuration files like
>
> ~/.gitconfig.in
> email = me@HOSTNAME@
>
> and then script something like sed -e "s/@HOSTNAME@/$(hostname)/" <
> ~/.gitconfig.in > ~/.gitconfig.
Yeah, substitution scripts like this are probably the simplest way to
go. Maybe some day it will make sense for commands to check the
timestamp or checksum of <foo>.in to automatically regenerate <foo> on
the fly when <foo>.in and other inputs change, but that sounds like
more complication than it's worth for git to take on.
Other alternatives might be to do that on the filesystem level (a FUSE
filesystem or Hurd-style translator generating determining the read(2)
result for <foo> on the fly), the editor level (vi knowing to
regenerate <foo> when you save <foo>.in), or the session management
level (bash via ~/.profile or ~/.bashrc or pam-login regenerating
<foo> at the start of each interactive session).
I wish there were an standard way to deal with such tasks instead of
running an update script manually, but now I'm getting off topic.
Thanks,
Jonathan
prev parent reply other threads:[~2013-08-10 20:19 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-08 15:09 Feature Request: Support logic or shell execution to control values in .gitconfig Morgan McClure
2013-08-08 15:23 ` Matthieu Moy
2013-08-08 15:47 ` Greg Troxel
2013-08-10 20:19 ` Jonathan Nieder [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=20130810201932.GA3031@elie.Belkin \
--to=jrnieder@gmail.com \
--cc=Matthieu.Moy@grenoble-inp.fr \
--cc=git@vger.kernel.org \
--cc=mcclure.morgan@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 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).