On Mon, Sep 26, 2011 at 10:13:44PM -0400, Jay Soffian wrote:
> > We could allow arbitrary shell code like:
> >
> > [include-if "test `uname -s` -eq Darwin"]
> >
> > Very flexible, though it makes me think we are getting a little
> > overboard. And it's an extra shell invocation whenever we read the
> > config, which is ugly.
>
> I would think git could just learn a few useful defines at the time of
> compile, such as e.g. OS_Darwin would be more than sufficient.
Yeah, I think that is probably more sane. We don't collect the
information now, but it probably wouldn't be that hard (at the very
worst, it would probably just involve running "uname" at build time).
> I can also give you another use use case. I keep all my work repos
> under ~Work/ and I want my user.email on all those to be my work email
> addy, and all other repos on my system I want to use my personal email
> address. So my ~/.gitconfig has my personal email address and then 99%
> of the time I forget to configure the repos under ~/Work correctly.
> That said, I'm not sure how the config include would help this...
You would need to provide git with some condition about which address
should be used. It sounds like the repo directory is the best bet. So
maybe something like:
[include-ifrepo "/home/jsoffian/Work/*"]
or something. Maybe that's too gross. I dunno.
FWIW, this hack would work even with current git:
cat >bin/git <<\EOF
#!/bin/sh
case "`git rev-parse --show-toplevel`" in
"$HOME/Work/*")
set -- -c user.email=whatever "$@"
;;
esac
exec /path/to/real/git "$@"
EOF
which would actually work with most of the conditionals that have been
mentioned in this thread. But it's kind of nasty.
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html