Re: [PATCH 1/2] clone: respect the settings in $HOME/.gitconfig and /etc/gitconfig

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 27 Jun 2008, Junio C Hamano wrote:

> Daniel Barkalow <barkalow@xxxxxxxxxxxx> writes:
> 
> > On Fri, 27 Jun 2008, Johannes Schindelin wrote:
> >
> >> After initializing the config in the newly-created repository, we
> >> need to unset GIT_CONFIG so that the global configs are read again.
> >
> > This seems fine to me. OTOH, I'm not sure the environment variable should 
> > be needed in the first place; I think the config stuff should look in 
> > git_path("config") without it, and we set the git dir to the one we're 
> > initializing. So I think the use of the environment variable is just an 
> > artifact of how the shell script did it and how I was originally calling 
> > the init_db stuff.
> >
> > Just removing the "setenv()" line survives all of the tests for me, and I 
> > remember some of them failing before I'd gotten some sort of solution for 
> > the config stuff.
> 
> Ok, I take that you are Ok with 2/2 but you have a better replacement
> patch coming for this 1/2?

I think so. Did we even make a commitment on whether:

GIT_CONFIG=foo git clone bar

must ignore the environment variable, or simply doesn't necessarily obey 
it? IIRC, the test scripts used to set GIT_CONFIG to something 
problematic (and would fail if clone didn't ignore it), but this was 
deemed incorrect usage and fixed. 

If it's okay to obey it (i.e., it gives the location of the config file 
for the clone):

------
Use all of the normal config-file handling in builtin-clone.c

There's no need to use the environment variable to direct the generation 
of the config file in the C version of clone, and having it not defined 
means that global and per-user configuration is available. This is 
necessary for the fetching portion, and could be useful someday for the 
init portion as well. It is unlikely that the user would want the 
repository's configuration in some non-default location, but no less 
likely than with any other git command besides "git config".

Signed-off-by: Daniel Barkalow <barkalow@xxxxxxxxxxxx>
---

diff --git a/builtin-clone.c b/builtin-clone.c
index f13845f..6dd58ac 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -415,8 +415,6 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
 	atexit(remove_junk);
 	signal(SIGINT, remove_junk_on_signal);
 
-	setenv(CONFIG_ENVIRONMENT, xstrdup(mkpath("%s/config", git_dir)), 1);
-
 	if (safe_create_leading_directories_const(git_dir) < 0)
 		die("could not create leading directories of '%s'", git_dir);
 	set_git_dir(make_absolute_path(git_dir));
--
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux