Junio C Hamano writes:
> On Wed, Aug 14, 2013 at 1:37 AM, Matthieu Moy
> wrote:
>>
>> Jeff King 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 don
On Wed, Aug 14, 2013 at 1:37 AM, Matthieu Moy
wrote:
>
> Jeff King 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
>
Jeff King 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 then
[core]
pager = less
# endif
That's rather ugly, a
On Wed, Aug 14, 2013 at 09:28:24AM +0200, Matthieu Moy wrote:
> Junio C Hamano writes:
>
> > Jeff King 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"
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 suggest
Junio C Hamano writes:
> Jeff King 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
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 t
Jeff King 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 are
Jeff King 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, rege
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 o
On 13 August 2013 21:46, Jeff King 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 I can thi
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 env
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
> m
On Mon, Aug 12, 2013 at 11:01:03PM +1000, Andrew Ardill wrote:
>On 12 August 2013 22:39, Jeff King 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 reposito
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
Felipe Contreras writes:
> This is how to implement that:
>
> From f1feaa05ce3772d8006078c4aeabcbd55b52d58e Mon Sep 17 00:00:00 2001
> From: Felipe Contreras 2nd
> Date: Tue, 13 Nov 2012 07:33:12 +0100
> Subject: [PATCH] ident: don't allow implicit email addresses
>
> Signed-off-by: Felipe Contr
Jonathan Nieder 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 unive
Junio C Hamano 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
http://www-verimag.imag.fr/~moy/
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 /etc/githooks/{pre,post}
On Mon, Aug 12, 2013 at 11:01:03PM +1000, Andrew Ardill wrote:
> On 12 August 2013 22:39, Jeff King 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 r
On 12 August 2013 22:39, Jeff King 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 great!
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 wrote:
>>> Perhaps we need a lighter-weight mechanism
>>>
>>> git init --profile=open
>>> git clone --profile=open git://git.kerne
Jeff King 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 clone a
On Mon, Aug 12, 2013 at 09:52:45PM +1000, Andrew Ardill wrote:
> On 11 August 2013 02:58, Junio C Hamano 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 d
On 11 August 2013 02:58, Junio C Hamano 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 folder to my
At 11:59 +0200 10 Aug 2013, 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 clone a repo, I *rely*
on Git reminding me to set use
Michael Haggerty writes:
> 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 intentiona
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
Jeff King 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
GPG Key f
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 th
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 co
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 ~/.g
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
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
On Fri, Aug 09, 2013 at 11:40:56PM -0700, Jonathan Nieder wrote:
> Jeff King wrote:
>
> > Even if it worked, though, I am not sure it would be worth such a rule.
> > The /etc/mailname file is not a standard, so you would effectively be
> > cutting off the auto-ident behavior for people on every o
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
Jeff King wrote:
> Even if it worked, though, I am not sure it would be worth such a rule.
> The /etc/mailname file is not a standard, so you would effectively be
> cutting off the auto-ident behavior for people on every other system. If
> we are going to do that, we might as well do it uniformly.
On Fri, Aug 09, 2013 at 04:06:16PM -0700, Junio C Hamano wrote:
> Jeff King 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
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 dom
Jeff King 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 have a d
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 gues
On Fri, Aug 9, 2013 at 3:00 PM, Thorsten Glaser 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 if user
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
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 e
44 matches
Mail list logo
