From: Matthew Persico <matthew.persico@gmail.com>
To: "SZEDER Gábor" <szeder@ira.uka.de>
Cc: Jeff King <peff@peff.net>, git@vger.kernel.org
Subject: Re: GIT_CONFIG - what's the point?
Date: Sun, 3 Apr 2016 16:11:55 -0400 [thread overview]
Message-ID: <CAL20dLAK953vmqO2E1Aw-4aDOCthJYu+xP=0GUX2DTmajLxi8A@mail.gmail.com> (raw)
In-Reply-To: <1459531705-31906-1-git-send-email-szeder@ira.uka.de>
On Fri, Apr 1, 2016 at 1:28 PM, SZEDER Gábor <szeder@ira.uka.de> wrote:
>> Let me explain my scenario. I have an nfs mounted home directory. It
>> is used across multiple machines. I use different colored xterms for
>> each machine. But that means that the one set of colors in my one
>> .gitconfig file don't work against all my screen backgrounds. I'm
>> trying to find a way to tune the git colors per login. The ability to
>> set colors in an environment variable (like most UNIX utils support)
>> would be the easiest way to do this. Failing that, I was hoping that
>> by setting GIT_CONFIG per login, I could tune the color schemes with
>> different config files.
>>
>> Since that is not how GIT_CONFIG is used, I have simply decided to
>> squint where necessary, or open up a neutral colored xterm for the
>> diff, regardless of machine.
>>
>> Yes, I could probably do diffs in many other ways, but git diff at the
>> command line is usually the most expedient.
>>
>> Unless I wanted to define a GIT_CONFIG_OVER environment variable upon
>> login, place inside it the appropriate -c<name>=<value> overrides for
>> colors, and then define a bash function git as
>>
>> git () {
>> $(which git) $GIT_CONFIG_OVER "$@"
>> return $?
>> }
>>
>> which seems silly.
>
> Yeah, that 'return $?' at the end of the function does indeed seem
> silly :) (sorry, couldn't resist...)
Part OCD, part OAC. :-)
>
> You could use machine-specific config includes instead of that
> GIT_CONFIG_OVER environment variable. I.e. store machine-specific
> color configuration in ~/.gitcolors.<machine> or something and define
> the shell function as:
>
> git () {
> command git -c include.path=~/.gitcolors.$HOSTNAME "$@"
> }
BINGO! THAT was the redirection I needed! One thing I was trying to
figure out early one was how to put HOSTNAME-based include.path-s in
the .gitconfig. So I put them OUTSIDE the .gitconfig like this.
Much obliged. Next time you are in NYC - I owe you a beer!
>
> The impact on your .bashrc would be much smaller than with the
> GIT_CONFIG_OVER approach.
> You could even turn this into an alias, if you want.
>
>
--
Matthew O. Persico
prev parent reply other threads:[~2016-04-03 20:12 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-01 0:54 GIT_CONFIG - what's the point? Matthew Persico
2016-04-01 11:19 ` Christian Couder
2016-04-01 12:38 ` Jeff King
2016-04-01 14:31 ` Matthew Persico
2016-04-01 14:53 ` Jeff King
2016-04-01 17:28 ` SZEDER Gábor
2016-04-03 20:11 ` Matthew Persico [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='CAL20dLAK953vmqO2E1Aw-4aDOCthJYu+xP=0GUX2DTmajLxi8A@mail.gmail.com' \
--to=matthew.persico@gmail.com \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
--cc=szeder@ira.uka.de \
/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).