On 08/13/2013 01:46 PM, Jeff King wrote:
On Tue, Aug 13, 2013 at 09:05:40PM +1000, Andrew Ardill wrote:
I applied this on top of latest next (1da3ebde8999d07), and it worked
perfectly for my use case.
For what it's worth, it also passed the test suite!
Would be great to see this, or
Junio C Hamano gits...@pobox.com writes:
Jeff King p...@peff.net writes:
I guess we could do something like:
[include repo:...your regex here...]
path = .gitconfig-only-for-some-repos
[include env:USE_MY_MAGIC_CONFIG]
path = .gitconfig-only-when-magic-env-set
I am not sure
On Wed, Aug 14, 2013 at 09:09:05AM +0200, Michael Haggerty wrote:
Gaaak! Let me again plead for supporting a post-clone hook rather than
inventing some crazy config-file syntax that is becoming ever more
complicated. A post-clone hook would make all of these things that have
been suggested
On Wed, Aug 14, 2013 at 09:28:24AM +0200, Matthieu Moy wrote:
Junio C Hamano gits...@pobox.com writes:
Jeff King p...@peff.net writes:
I guess we could do something like:
[include repo:...your regex here...]
path = .gitconfig-only-for-some-repos
[include
Jeff King p...@peff.net writes:
This whole discussion is basically implementing conditional config.
[...] The problem is that it would be tricky to do in a
backwards-compatible way.
That could be done with conditional comments like
# if some-condition then
[core]
pager = less
# endif
On Wed, Aug 14, 2013 at 1:37 AM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
Jeff King p...@peff.net writes:
This whole discussion is basically implementing conditional config.
[...] The problem is that it would be tricky to do in a
backwards-compatible way.
That could be done with
Junio C Hamano gits...@pobox.com writes:
On Wed, Aug 14, 2013 at 1:37 AM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
Jeff King p...@peff.net writes:
This whole discussion is basically implementing conditional config.
[...] The problem is that it would be tricky to do in a
Junio C Hamano gits...@pobox.com writes:
(2) configure include.path to point at ~/.git-profile/open at
the very end
I'd rather have it ~/.config/git/profile/ (or
$XDG_CONFIG_HOME/git/profile if $XDG_CONFIG_HOME is set), but the
proposal makes sense.
--
Matthieu Moy
Jonathan Nieder jrnie...@gmail.com writes:
Hi Thorsten,
Thorsten Glaser wrote[1]:
git config user.email SHOULD NOT default to $(id -un)@$(hostname -f)
because just too many cow-orkers seem to be unable to follow basic
instructions
Heh.
Can you say a little more about your setup? In a
Felipe Contreras felipe.contre...@gmail.com writes:
This is how to implement that:
From f1feaa05ce3772d8006078c4aeabcbd55b52d58e Mon Sep 17 00:00:00 2001
From: Felipe Contreras 2nd felipe.contrera...@gmail.com
Date: Tue, 13 Nov 2012 07:33:12 +0100
Subject: [PATCH] ident: don't allow
Matthieu Moy dixit:
An opt-in auto-detection would be cool for people who really work in a
controlled environment, so that the sysadmin could enable it from
Sounds like a plan ;-)
I think with several people chiming in on this, while that proposal
would affect a majority of people, it would do
On Mon, Aug 12, 2013 at 11:01:03PM +1000, Andrew Ardill wrote:
On 12 August 2013 22:39, Jeff King p...@peff.net wrote:
We could do something like the patch below, which allows:
$ git config --global include./magic/.path .gitconfig-magic
to read ~/.gitconfig-magic only when we are in a
On Tue, Aug 13, 2013 at 09:05:40PM +1000, Andrew Ardill wrote:
I applied this on top of latest next (1da3ebde8999d07), and it worked
perfectly for my use case.
For what it's worth, it also passed the test suite!
Would be great to see this, or something on the same theme, get into
master.
On Tue, Aug 13, 2013 at 07:46:35AM -0400, Jeff King wrote:
The only downside I can think of is that we might want to use the
subsection in include.SUBSECTION.* for some other limiting conditions
(e.g., only include this config when running version = X.Y, or even
include only when environment
On 13 August 2013 21:46, Jeff King p...@peff.net wrote:
Like I said, I do not have a particular use for it, but I don't think it
would hurt anybody who does not use it. If you want to polish it up into
a real patch with docs and tests, I don't mind.
I'll have a go at this.
The only downside
On Tue, Aug 13, 2013 at 10:52:34PM +1000, Andrew Ardill wrote:
The only downside I can think of is that we might want to use the
subsection in include.SUBSECTION.* for some other limiting conditions
(e.g., only include this config when running version = X.Y, or even
include only when
Jeff King p...@peff.net writes:
diff --git a/config.c b/config.c
index e13a7b6..a31dc85 100644
--- a/config.c
+++ b/config.c
@@ -119,10 +119,45 @@ int git_config_include(const char *var, const char
*value, void *data)
return ret;
}
+static NORETURN void die_bad_regex(int err,
Jeff King p...@peff.net writes:
I guess we could do something like:
[include repo:...your regex here...]
path = .gitconfig-only-for-some-repos
[include env:USE_MY_MAGIC_CONFIG]
path = .gitconfig-only-when-magic-env-set
I am not sure if env is very useful, but there certainly
On 11 August 2013 02:58, Junio C Hamano gits...@pobox.com wrote:
Perhaps we need a lighter-weight mechanism
git init --profile=open
git clone --profile=open git://git.kernel.org/git.git
This is something I would definitely use.
All of my work git directories are in a separate
On Mon, Aug 12, 2013 at 09:52:45PM +1000, Andrew Ardill wrote:
On 11 August 2013 02:58, Junio C Hamano gits...@pobox.com wrote:
Perhaps we need a lighter-weight mechanism
git init --profile=open
git clone --profile=open git://git.kernel.org/git.git
This is something I
Jeff King p...@peff.net writes:
On Sat, Aug 10, 2013 at 11:59:21AM +0200, Michael Haggerty wrote:
I intentionally don't set user.email in my ~/.gitconfig because I use
different identities (on the same machine) depending on what project I
am committing to (open-source vs. work). After I
On 08/12/2013 02:39 PM, Jeff King wrote:
On Mon, Aug 12, 2013 at 09:52:45PM +1000, Andrew Ardill wrote:
On 11 August 2013 02:58, Junio C Hamano gits...@pobox.com wrote:
Perhaps we need a lighter-weight mechanism
git init --profile=open
git clone --profile=open
On 12 August 2013 22:39, Jeff King p...@peff.net wrote:
We could do something like the patch below, which allows:
$ git config --global include./magic/.path .gitconfig-magic
to read ~/.gitconfig-magic only when we are in a repository with a
directory component /magic/.
Thanks, this looks
On Mon, Aug 12, 2013 at 11:01:03PM +1000, Andrew Ardill wrote:
On 12 August 2013 22:39, Jeff King p...@peff.net wrote:
We could do something like the patch below, which allows:
$ git config --global include./magic/.path .gitconfig-magic
to read ~/.gitconfig-magic only when we are in
On Mon, Aug 12, 2013 at 02:54:13PM +0200, Michael Haggerty wrote:
We could satisfy a whole class of wishes by supporting
user-wide/system-wide git hooks like
~/.githooks/{pre,post}-clone /etc/githooks/{pre,post}-clone
~/.githooks/{pre,post}-init
On Fri, Aug 09, 2013 at 04:06:16PM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
Yeah, there are basically three levels of ident:
1. The user told us explicitly (e.g., $EMAIL, user.email). Trust it.
2. We guessed and it looks reasonable (e.g., hostname is FQDN).
On Fri, Aug 09, 2013 at 04:19:28PM -0700, Jonathan Nieder wrote:
Jeff King wrote:
Yeah, there are basically three levels of ident:
1. The user told us explicitly (e.g., $EMAIL, user.email). Trust it.
2. We guessed and it looks reasonable (e.g., hostname is FQDN). Warn
but
Jeff King wrote:
Sorry to be unclear. I meant that treating /etc/mailname and gethostname
differently might be justified on Debian under the logic if you have
/etc/mailname, that is a trustworthy address, and if you do not, then we
cannot guess at a trustworthy address (because putting it in
On Sat, Aug 10, 2013 at 12:03:00AM -0700, Jonathan Nieder wrote:
Jeff King wrote:
Sorry to be unclear. I meant that treating /etc/mailname and gethostname
differently might be justified on Debian under the logic if you have
/etc/mailname, that is a trustworthy address, and if you do not,
On 08/10/2013 08:47 AM, Jeff King wrote:
But I think MX records and deliverability is beside the point. Even in a
case where we come up with a valid, deliverable address, is that what
the user wants to have in their commit history for all time?
I intentionally don't set user.email in my
On Sat, Aug 10, 2013 at 11:59:21AM +0200, Michael Haggerty wrote:
On 08/10/2013 08:47 AM, Jeff King wrote:
But I think MX records and deliverability is beside the point. Even in a
case where we come up with a valid, deliverable address, is that what
the user wants to have in their commit
On 08/10/2013 12:28 PM, Jeff King wrote:
On Sat, Aug 10, 2013 at 11:59:21AM +0200, Michael Haggerty wrote:
On 08/10/2013 08:47 AM, Jeff King wrote:
But I think MX records and deliverability is beside the point. Even in a
case where we come up with a valid, deliverable address, is that what
Jeff King p...@peff.net writes:
So if I understand your use case, then you would be even happier if
rather than giving a warning, git simply barfed and said please set
your identity before committing?
FWIW, this is what both hg and bzr do.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
Jeff King dixit:
It was not clear to me whether his site has /etc/mailname. If it does
Some may, some may not but…
But from his description, the machine may even have a split-horizon name
in /etc/mailname, and we can do nothing at all about that.
… that won’t happen. The problem is that they
Hi Thorsten,
Thorsten Glaser wrote[1]:
git config user.email SHOULD NOT default to $(id -un)@$(hostname -f)
because just too many cow-orkers seem to be unable to follow basic
instructions
Heh.
Can you say a little more about your setup? In a university
environment with sysadmin-managed
Jonathan Nieder dixit:
Can you say a little more about your setup? In a university
environment with sysadmin-managed email and /etc/mailname set up
correctly it is handy that people can start working without doing
Ah okay. We don’t have /etc/mailname set up I think and,
additionally, the Unix
On Fri, Aug 9, 2013 at 3:00 PM, Thorsten Glaser t...@mirbsd.de wrote:
Jonathan Nieder dixit:
I wonder if it's too gentle and long to get the point across. Would
something the following (including the guesses in the message for
easier copy-pasting) help?
Definitely not. It needs to fail hard
On Fri, Aug 09, 2013 at 12:42:14PM -0700, Jonathan Nieder wrote:
I wonder if it's too gentle and long to get the point across. Would
something the following (including the guesses in the message for
easier copy-pasting) help?
No name and email address configured, so I had to guess.
Jeff King p...@peff.net writes:
Yeah, there are basically three levels of ident:
1. The user told us explicitly (e.g., $EMAIL, user.email). Trust it.
2. We guessed and it looks reasonable (e.g., hostname is FQDN). Warn
but use it.
3. It looks obviously bogus (e.g., we do not
Jeff King wrote:
Yeah, there are basically three levels of ident:
1. The user told us explicitly (e.g., $EMAIL, user.email). Trust it.
2. We guessed and it looks reasonable (e.g., hostname is FQDN). Warn
but use it.
3. It looks obviously bogus (e.g., we do not have a domain
40 matches
Mail list logo
