Feature Request: Support logic or shell execution to control values in .gitconfig

I sync all my dot files (including .gitconfig) among several machines and it's currently not possible to put conditional logic in many fields (any that aren't considered strings to be executed as shell commands ie aliases, editor, etc).

My specific use case is the email address. Normally I want my email address to read: mcclurem@$HOSTNAME <mcclure.morgan@gmail.com>

I use this to track which machine I'm committing from etc.

I propose using something reminiscent of bash syntax, either: value = $(SOMETEXTTOEXECUTE)

or

value = `SOMETEXTTOEXECUTE`

Is this a feature others could get behind?

-Morgan McClure

Morgan McClure <mcclure.morgan@gmail.com> writes:

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).

* A performance issue with the current git implementation, as the config
  file may be read many time for a single git execution.

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.

You may also use the include.path functionality to share most of your configuration, and include a small file which is different on each host.

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

For what it's worth, I

  keep dotfiles checked in as m4 sources, which is more or less
  equivalent to Matthieu's suggestion of sed

  don't try to keep .gitconfig under source control, but instead have a
  "git-config" alias that executes a lot of "git config --global"
  commands.

The downsides to the git-config shell function approach are:

  unwanted configurations are not removed

  one has to source (e.g.) .bash_aliases and then rerun git-config after
  updating the dotfile repo,

I suspect what's really needed is some sort of two-way macro preprocessor that can take changes in an output file an back them into the source.

Matthieu Moy wrote:

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.

This issue is harder.

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