{"thread":{"id":"14180","subject":"Using url.insteadOf in git-clone","startedAt":"2008-06-27T09:35:02Z","lastAt":"2008-06-30T16:47:04Z","messageCount":26,"participants":["Pieter de Bie","Johannes Schindelin","Daniel Barkalow","Junio C Hamano","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"81375","messageId":"27C25D70-0BFC-4362-A771-C7CAD89BC198@ai.rug.nl","threadId":"14180","inReplyTo":null,"subject":"Using url.insteadOf in git-clone","fromName":"Pieter de Bie","fromEmail":"pdebie@ai.rug.nl","sentAt":"2008-06-27T09:35:02Z","receivedAt":"2008-06-27T09:35:02Z","isPatch":false,"sender":{"key":"pdebie@ai.rug.nl","avatar":null},"body":"Hi,\n\nI sometimes use url.insteadOf to create a shortcut to a central  \nrepository.\nFor example, having something like[*1*]\n\n[url \"git://repo.or.cz/git/\"]\n\tinsteadOf = \"repo:\"\n\nin my global gitconfig allows me to do a 'git fetch repo:dscho.git'.  \nI'd also\nlike to use that with git clone :). Currently if I try that, I get\n\nVienna:~ pieter$ git clone repo:dscho.git\nInitialize dscho/.git\nInitialized empty Git repository in /Users/pieter/dscho/.git/\nssh: Error resolving hostname repo: nodename nor servname provided, or  \nnot known\nfatal: The remote end hung up unexpectedly\n\nWhich I think comes from the fact that the global config isn't read in  \nby\nremote.c when running git clone.\n\nNow, I seem to remember there was a good reason for this (both builtin- \nclone\nand git-clone.sh have the same behaviour). Also, trying to quickly  \nhack in\nsomething failed for me, even though it seems like a trivial change to  \nmake\nfor someone more familiar with the code path.\n\nIs there an easy fix for this?\n\n- Pieter\n\n[1] This is not really true. If I try that, I get an error:\nVienna:git pieter$ git fetch -v repo:dscho.git\nfatal: I don't handle protocol 'it'\n\nIf I change the url to \"ggit://..\" it does work. It seems there is an  \noff-by-one\nerror somewhere? It does work for another url.insteadOf I have in my  \nglobal\nconfig though..\n"},{"id":"81386","messageId":"alpine.DEB.1.00.0806271353350.9925@racer","threadId":"14180","inReplyTo":"27C25D70-0BFC-4362-A771-C7CAD89BC198@ai.rug.nl","subject":"[PATCH 1/2] clone: respect the settings in $HOME/.gitconfig and /etc/gitconfig","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-06-27T12:55:23Z","receivedAt":"2008-06-27T12:55:23Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"\nAfter initializing the config in the newly-created repository, we\nneed to unset GIT_CONFIG so that the global configs are read again.\n\nNoticed by Pieter de Bie.\n\nSigned-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>\n---\n\n\tOn Fri, 27 Jun 2008, Pieter de Bie wrote:\n\n\t> I sometimes use url.insteadOf to create a shortcut to a central \n\t> repository. For example, having something like[*1*]\n\t> \n\t> [url \"git://repo.or.cz/git/\"]\n\t> \tinsteadOf = \"repo:\"\n\t> \n\t> in my global gitconfig allows me to do a 'git fetch \n\t> repo:dscho.git'. I'd also like to use that with git clone :).\n\t> Currently if I try that, I get\n\t> \n\t> Vienna:~ pieter$ git clone repo:dscho.git\n\t> Initialize dscho/.git\n\t> Initialized empty Git repository in /Users/pieter/dscho/.git/\n\t> ssh: Error resolving hostname repo: nodename nor servname provided,\n\t>\tor not known\n\t> fatal: The remote end hung up unexpectedly\n\t> \n\t> [...]\n\t>\n\t> Is there an easy fix for this?\n\n\tYes ;-)\n\n builtin-clone.c |    7 +++++++\n 1 files changed, 7 insertions(+), 0 deletions(-)\n\ndiff --git a/builtin-clone.c b/builtin-clone.c\nindex 17baa20..965b5fc 100644\n--- a/builtin-clone.c\n+++ b/builtin-clone.c\n@@ -424,6 +424,13 @@ int cmd_clone(int argc, const char **argv, const char *prefix)\n \tfprintf(stderr, \"Initialize %s\\n\", git_dir);\n \tinit_db(option_template, option_quiet ? INIT_DB_QUIET : 0);\n \n+\t/*\n+\t * At this point, the config exists, so we do not need the\n+\t * environment variable.  We actually need to unset it, too, to\n+\t * re-enable parsing of the global configs.\n+\t */\n+\tunsetenv(CONFIG_ENVIRONMENT);\n+\n \tif (option_reference)\n \t\tsetup_reference(git_dir);\n \n-- \n1.5.6.173.gde14c\n"},{"id":"81387","messageId":"alpine.DEB.1.00.0806271355520.9925@racer","threadId":"14180","inReplyTo":"alpine.DEB.1.00.0806271353350.9925@racer","subject":"[PATCH 2/2] clone: respect url.insteadOf setting in global configs","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-06-27T12:56:05Z","receivedAt":"2008-06-27T12:56:05Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"\nWhen we call \"git clone\" with a url that has a rewrite rule in either\n$HOME/.gitconfig or /etc/gitconfig, the URL can be different from\nwhat the command line expects it to be.\n\nSo, let's use the URL as the remote structure has it, not the literal\nstring from the command line.\n\nNoticed by Pieter de Bie.\n\nSigned-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>\n---\n builtin-clone.c |    3 ++-\n 1 files changed, 2 insertions(+), 1 deletions(-)\n\ndiff --git a/builtin-clone.c b/builtin-clone.c\nindex 965b5fc..8dda52a 100644\n--- a/builtin-clone.c\n+++ b/builtin-clone.c\n@@ -463,7 +463,8 @@ int cmd_clone(int argc, const char **argv, const char *prefix)\n \t\trefs = clone_local(path, git_dir);\n \telse {\n \t\tstruct remote *remote = remote_get(argv[0]);\n-\t\tstruct transport *transport = transport_get(remote, argv[0]);\n+\t\tstruct transport *transport =\n+\t\t\ttransport_get(remote, remote->url[0]);\n \n \t\tif (!transport->get_refs_list || !transport->fetch)\n \t\t\tdie(\"Don't know how to clone %s\", transport->url);\n-- \n1.5.6.173.gde14c\n"},{"id":"81414","messageId":"alpine.LNX.1.00.0806271149580.19665@iabervon.org","threadId":"14180","inReplyTo":"alpine.DEB.1.00.0806271353350.9925@racer","subject":"Re: [PATCH 1/2] clone: respect the settings in $HOME/.gitconfig and /etc/gitconfig","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-06-27T16:05:39Z","receivedAt":"2008-06-27T16:05:39Z","isPatch":true,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Fri, 27 Jun 2008, Johannes Schindelin wrote:\n\n> After initializing the config in the newly-created repository, we\n> need to unset GIT_CONFIG so that the global configs are read again.\n\nThis seems fine to me. OTOH, I'm not sure the environment variable should \nbe needed in the first place; I think the config stuff should look in \ngit_path(\"config\") without it, and we set the git dir to the one we're \ninitializing. So I think the use of the environment variable is just an \nartifact of how the shell script did it and how I was originally calling \nthe init_db stuff.\n\nJust removing the \"setenv()\" line survives all of the tests for me, and I \nremember some of them failing before I'd gotten some sort of solution for \nthe config stuff.\n\n> Noticed by Pieter de Bie.\n\nYou'd think I would have noticed this, since I mainly decided to convert \nclone to C so that url.insteadOf in global config would let you do \"git \nclone work:modulename\", but I clearly never tested it.\n\n> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>\n> ---\n> \n> \tOn Fri, 27 Jun 2008, Pieter de Bie wrote:\n> \n> \t> I sometimes use url.insteadOf to create a shortcut to a central \n> \t> repository. For example, having something like[*1*]\n> \t> \n> \t> [url \"git://repo.or.cz/git/\"]\n> \t> \tinsteadOf = \"repo:\"\n> \t> \n> \t> in my global gitconfig allows me to do a 'git fetch \n> \t> repo:dscho.git'. I'd also like to use that with git clone :).\n> \t> Currently if I try that, I get\n> \t> \n> \t> Vienna:~ pieter$ git clone repo:dscho.git\n> \t> Initialize dscho/.git\n> \t> Initialized empty Git repository in /Users/pieter/dscho/.git/\n> \t> ssh: Error resolving hostname repo: nodename nor servname provided,\n> \t>\tor not known\n> \t> fatal: The remote end hung up unexpectedly\n> \t> \n> \t> [...]\n> \t>\n> \t> Is there an easy fix for this?\n> \n> \tYes ;-)\n> \n>  builtin-clone.c |    7 +++++++\n>  1 files changed, 7 insertions(+), 0 deletions(-)\n> \n> diff --git a/builtin-clone.c b/builtin-clone.c\n> index 17baa20..965b5fc 100644\n> --- a/builtin-clone.c\n> +++ b/builtin-clone.c\n> @@ -424,6 +424,13 @@ int cmd_clone(int argc, const char **argv, const char *prefix)\n>  \tfprintf(stderr, \"Initialize %s\\n\", git_dir);\n>  \tinit_db(option_template, option_quiet ? INIT_DB_QUIET : 0);\n>  \n> +\t/*\n> +\t * At this point, the config exists, so we do not need the\n> +\t * environment variable.  We actually need to unset it, too, to\n> +\t * re-enable parsing of the global configs.\n> +\t */\n> +\tunsetenv(CONFIG_ENVIRONMENT);\n> +\n>  \tif (option_reference)\n>  \t\tsetup_reference(git_dir);\n>  \n> -- \n> 1.5.6.173.gde14c\n> \n> \n"},{"id":"81415","messageId":"alpine.LNX.1.00.0806271205430.19665@iabervon.org","threadId":"14180","inReplyTo":"alpine.DEB.1.00.0806271355520.9925@racer","subject":"Re: [PATCH 2/2] clone: respect url.insteadOf setting in global configs","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-06-27T16:08:53Z","receivedAt":"2008-06-27T16:08:53Z","isPatch":true,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Fri, 27 Jun 2008, Johannes Schindelin wrote:\n\n> When we call \"git clone\" with a url that has a rewrite rule in either\n> $HOME/.gitconfig or /etc/gitconfig, the URL can be different from\n> what the command line expects it to be.\n> \n> So, let's use the URL as the remote structure has it, not the literal\n> string from the command line.\n\nThis is how it should be.\n\nMaybe I ought to make transport_get() take the index of the URL in the \nlist for the remote, instead of taking the actual URL; any use of a URL \nthat's not from that list is going to be oddly wrong in some way, I think.\n\nThanks for taking care of this.\n\n> Noticed by Pieter de Bie.\n> \n> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>\n> ---\n>  builtin-clone.c |    3 ++-\n>  1 files changed, 2 insertions(+), 1 deletions(-)\n> \n> diff --git a/builtin-clone.c b/builtin-clone.c\n> index 965b5fc..8dda52a 100644\n> --- a/builtin-clone.c\n> +++ b/builtin-clone.c\n> @@ -463,7 +463,8 @@ int cmd_clone(int argc, const char **argv, const char *prefix)\n>  \t\trefs = clone_local(path, git_dir);\n>  \telse {\n>  \t\tstruct remote *remote = remote_get(argv[0]);\n> -\t\tstruct transport *transport = transport_get(remote, argv[0]);\n> +\t\tstruct transport *transport =\n> +\t\t\ttransport_get(remote, remote->url[0]);\n>  \n>  \t\tif (!transport->get_refs_list || !transport->fetch)\n>  \t\t\tdie(\"Don't know how to clone %s\", transport->url);\n> -- \n> 1.5.6.173.gde14c\n> \n> \n> \n"},{"id":"81440","messageId":"7vbq1msszw.fsf@gitster.siamese.dyndns.org","threadId":"14180","inReplyTo":"27C25D70-0BFC-4362-A771-C7CAD89BC198@ai.rug.nl","subject":"Re: Using url.insteadOf in git-clone","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-06-27T17:11:15Z","receivedAt":"2008-06-27T17:11:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Pieter de Bie <pdebie@ai.rug.nl> writes:\n\n> [1] This is not really true. If I try that, I get an error:\n> Vienna:git pieter$ git fetch -v repo:dscho.git\n> fatal: I don't handle protocol 'it'\n>\n> If I change the url to \"ggit://..\" it does work. It seems there is an\n> off-by-one\n> error somewhere? It does work for another url.insteadOf I have in my\n> global\n> config though..\n\nWhat version of git is this?\n\nv1.5.5.1 and later contains 60e3aba (Fix config key miscount in\nurl.*.insteadOf, 2008-04-12).\n"},{"id":"81507","messageId":"7vvdzuo61b.fsf@gitster.siamese.dyndns.org","threadId":"14180","inReplyTo":"alpine.LNX.1.00.0806271149580.19665@iabervon.org","subject":"Re: [PATCH 1/2] clone: respect the settings in $HOME/.gitconfig and /etc/gitconfig","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-06-27T22:40:48Z","receivedAt":"2008-06-27T22:40:48Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow <barkalow@iabervon.org> writes:\n\n> On Fri, 27 Jun 2008, Johannes Schindelin wrote:\n>\n>> After initializing the config in the newly-created repository, we\n>> need to unset GIT_CONFIG so that the global configs are read again.\n>\n> This seems fine to me. OTOH, I'm not sure the environment variable should \n> be needed in the first place; I think the config stuff should look in \n> git_path(\"config\") without it, and we set the git dir to the one we're \n> initializing. So I think the use of the environment variable is just an \n> artifact of how the shell script did it and how I was originally calling \n> the init_db stuff.\n>\n> Just removing the \"setenv()\" line survives all of the tests for me, and I \n> remember some of them failing before I'd gotten some sort of solution for \n> the config stuff.\n\nOk, I take that you are Ok with 2/2 but you have a better replacement\npatch coming for this 1/2?\n"},{"id":"81654","messageId":"alpine.LNX.1.00.0806291359330.19665@iabervon.org","threadId":"14180","inReplyTo":"7vvdzuo61b.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH 1/2] clone: respect the settings in $HOME/.gitconfig and /etc/gitconfig","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-06-29T18:31:56Z","receivedAt":"2008-06-29T18:31:56Z","isPatch":true,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Fri, 27 Jun 2008, Junio C Hamano wrote:\n\n> Daniel Barkalow <barkalow@iabervon.org> writes:\n> \n> > On Fri, 27 Jun 2008, Johannes Schindelin wrote:\n> >\n> >> After initializing the config in the newly-created repository, we\n> >> need to unset GIT_CONFIG so that the global configs are read again.\n> >\n> > This seems fine to me. OTOH, I'm not sure the environment variable should \n> > be needed in the first place; I think the config stuff should look in \n> > git_path(\"config\") without it, and we set the git dir to the one we're \n> > initializing. So I think the use of the environment variable is just an \n> > artifact of how the shell script did it and how I was originally calling \n> > the init_db stuff.\n> >\n> > Just removing the \"setenv()\" line survives all of the tests for me, and I \n> > remember some of them failing before I'd gotten some sort of solution for \n> > the config stuff.\n> \n> Ok, I take that you are Ok with 2/2 but you have a better replacement\n> patch coming for this 1/2?\n\nI think so. Did we even make a commitment on whether:\n\nGIT_CONFIG=foo git clone bar\n\nmust ignore the environment variable, or simply doesn't necessarily obey \nit? IIRC, the test scripts used to set GIT_CONFIG to something \nproblematic (and would fail if clone didn't ignore it), but this was \ndeemed incorrect usage and fixed. \n\nIf it's okay to obey it (i.e., it gives the location of the config file \nfor the clone):\n\n------\nUse all of the normal config-file handling in builtin-clone.c\n\nThere's no need to use the environment variable to direct the generation \nof the config file in the C version of clone, and having it not defined \nmeans that global and per-user configuration is available. This is \nnecessary for the fetching portion, and could be useful someday for the \ninit portion as well. It is unlikely that the user would want the \nrepository's configuration in some non-default location, but no less \nlikely than with any other git command besides \"git config\".\n\nSigned-off-by: Daniel Barkalow <barkalow@iabervon.org>\n---\n\ndiff --git a/builtin-clone.c b/builtin-clone.c\nindex f13845f..6dd58ac 100644\n--- a/builtin-clone.c\n+++ b/builtin-clone.c\n@@ -415,8 +415,6 @@ int cmd_clone(int argc, const char **argv, const char *prefix)\n \tatexit(remove_junk);\n \tsignal(SIGINT, remove_junk_on_signal);\n \n-\tsetenv(CONFIG_ENVIRONMENT, xstrdup(mkpath(\"%s/config\", git_dir)), 1);\n-\n \tif (safe_create_leading_directories_const(git_dir) < 0)\n \t\tdie(\"could not create leading directories of '%s'\", git_dir);\n \tset_git_dir(make_absolute_path(git_dir));\n"},{"id":"81656","messageId":"70C8B09D-0320-48E8-BEC8-5A75BBBA6364@ai.rug.nl","threadId":"14180","inReplyTo":"7vbq1msszw.fsf@gitster.siamese.dyndns.org","subject":"Re: Using url.insteadOf in git-clone","fromName":"Pieter de Bie","fromEmail":"pdebie@ai.rug.nl","sentAt":"2008-06-29T18:59:11Z","receivedAt":"2008-06-29T18:59:11Z","isPatch":false,"sender":{"key":"pdebie@ai.rug.nl","avatar":null},"body":"\nOn 27 jun 2008, at 19:11, Junio C Hamano wrote:\n\n> Pieter de Bie <pdebie@ai.rug.nl> writes:\n>\n>> [1] This is not really true. If I try that, I get an error:\n>> Vienna:git pieter$ git fetch -v repo:dscho.git\n>> fatal: I don't handle protocol 'it'\n>>\n>> If I change the url to \"ggit://..\" it does work. It seems there is an\n>> off-by-one\n>> error somewhere? It does work for another url.insteadOf I have in my\n>> global\n>> config though..\n>\n> What version of git is this?\n>\n> v1.5.5.1 and later contains 60e3aba (Fix config key miscount in\n> url.*.insteadOf, 2008-04-12).\n>\n\nI think I tried this while testing the 1.5.5 clone.sh, so that's  \nprobably it.\nThanks.\n\n\n- Pieter\n"},{"id":"81662","messageId":"770C18A6-429E-49C0-BCF3-C2B229AAF5F9@ai.rug.nl","threadId":"14180","inReplyTo":"alpine.DEB.1.00.0806271355520.9925@racer","subject":"Re: [PATCH 2/2] clone: respect url.insteadOf setting in global configs","fromName":"Pieter de Bie","fromEmail":"pdebie@ai.rug.nl","sentAt":"2008-06-29T20:12:49Z","receivedAt":"2008-06-29T20:12:49Z","isPatch":true,"sender":{"key":"pdebie@ai.rug.nl","avatar":null},"body":"\nOn 27 jun 2008, at 14:56, Johannes Schindelin wrote:\n\n> When we call \"git clone\" with a url that has a rewrite rule in either\n> $HOME/.gitconfig or /etc/gitconfig, the URL can be different from\n> what the command line expects it to be.\n>\n> So, let's use the URL as the remote structure has it, not the literal\n> string from the command line.\n>\n> Noticed by Pieter de Bie.\n\n\nThis works great, thanks for the quick patch! :)\n\n- Pieter\n"},{"id":"81670","messageId":"7vprq07zco.fsf@gitster.siamese.dyndns.org","threadId":"14180","inReplyTo":"alpine.LNX.1.00.0806291359330.19665@iabervon.org","subject":"Re: [PATCH 1/2] clone: respect the settings in $HOME/.gitconfig and /etc/gitconfig","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-06-29T20:36:23Z","receivedAt":"2008-06-29T20:36:23Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow <barkalow@iabervon.org> writes:\n\n> There's no need to use the environment variable to direct the generation \n> of the config file in the C version of clone, and having it not defined \n> means that global and per-user configuration is available. This is \n> necessary for the fetching portion, and could be useful someday for the \n> init portion as well. It is unlikely that the user would want the \n> repository's configuration in some non-default location, but no less \n> likely than with any other git command besides \"git config\".\n>\n> Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>\n\nThanks, will queue together with the earlier [2/2] from Dscho.\n\nCan we have updates to the testsuite as well?  We would probably have to\nfudge $HOME and have some entries in $HOME/.gitconfig to simulate the\nsituation that triggered the original discussion.\n"},{"id":"81673","messageId":"alpine.DEB.1.00.0806292248160.9925@racer","threadId":"14180","inReplyTo":"alpine.LNX.1.00.0806291359330.19665@iabervon.org","subject":"Re: [PATCH 1/2] clone: respect the settings in $HOME/.gitconfig and /etc/gitconfig","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-06-29T21:49:42Z","receivedAt":"2008-06-29T21:49:42Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 29 Jun 2008, Daniel Barkalow wrote:\n\n> Did we even make a commitment on whether:\n> \n> GIT_CONFIG=foo git clone bar\n> \n> must ignore the environment variable, or simply doesn't necessarily obey \n> it?\n\nI'd rather strongly argue that no matter what is the answer to this \nquestion, we _HAVE TO_ unsetenv() GIT_CONFIG at some stage, otherwise no \n.git/config will be written.\n\nSo, this is a NACK on your patch.\n\nCiao,\nDscho\n"},{"id":"81674","messageId":"alpine.DEB.1.00.0806292250220.9925@racer","threadId":"14180","inReplyTo":"770C18A6-429E-49C0-BCF3-C2B229AAF5F9@ai.rug.nl","subject":"Re: [PATCH 2/2] clone: respect url.insteadOf setting in global configs","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-06-29T21:50:34Z","receivedAt":"2008-06-29T21:50:34Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 29 Jun 2008, Pieter de Bie wrote:\n\n> On 27 jun 2008, at 14:56, Johannes Schindelin wrote:\n> \n> > When we call \"git clone\" with a url that has a rewrite rule in either\n> > $HOME/.gitconfig or /etc/gitconfig, the URL can be different from\n> > what the command line expects it to be.\n> >\n> > So, let's use the URL as the remote structure has it, not the literal\n> > string from the command line.\n> >\n> > Noticed by Pieter de Bie.\n> \n> \n> This works great, thanks for the quick patch! :)\n\nThanks for the quick answer,\nDscho\n"},{"id":"81683","messageId":"alpine.LNX.1.00.0806291821520.19665@iabervon.org","threadId":"14180","inReplyTo":"alpine.DEB.1.00.0806292248160.9925@racer","subject":"Re: [PATCH 1/2] clone: respect the settings in $HOME/.gitconfig and /etc/gitconfig","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-06-29T22:47:33Z","receivedAt":"2008-06-29T22:47:33Z","isPatch":true,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sun, 29 Jun 2008, Johannes Schindelin wrote:\n\n> Hi,\n> \n> On Sun, 29 Jun 2008, Daniel Barkalow wrote:\n> \n> > Did we even make a commitment on whether:\n> > \n> > GIT_CONFIG=foo git clone bar\n> > \n> > must ignore the environment variable, or simply doesn't necessarily obey \n> > it?\n> \n> I'd rather strongly argue that no matter what is the answer to this \n> question, we _HAVE TO_ unsetenv() GIT_CONFIG at some stage, otherwise no \n> .git/config will be written.\n\nWhy should .git/config get written? The user is explicitly using a \ndifferent file instead, so .git/config really shouldn't get written, \nunless the user isn't allowed to use the environment variable or the \nenvironment variable shouldn't apply.\n\nActually, perhaps the right thing is to remove the code to look at the \nenvironment variable from config.c and have it in builtin-config.c, since \nonly \"git config\" is actually documented to be affected by GIT_CONFIG at \nall. But I don't really know what the variable is supposed to do, beyond \nwhat's in the documentation. In any case, I don't think \"git clone\" is at \nall special with respect to GIT_CONFIG.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"81690","messageId":"alpine.DEB.1.00.0806300134200.9925@racer","threadId":"14180","inReplyTo":"alpine.LNX.1.00.0806291821520.19665@iabervon.org","subject":"Re: [PATCH 1/2] clone: respect the settings in $HOME/.gitconfig and /etc/gitconfig","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-06-30T00:41:54Z","receivedAt":"2008-06-30T00:41:54Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 29 Jun 2008, Daniel Barkalow wrote:\n\n> On Sun, 29 Jun 2008, Johannes Schindelin wrote:\n> \n> > On Sun, 29 Jun 2008, Daniel Barkalow wrote:\n> > \n> > > Did we even make a commitment on whether:\n> > > \n> > > GIT_CONFIG=foo git clone bar\n> > > \n> > > must ignore the environment variable, or simply doesn't necessarily \n> > > obey it?\n> > \n> > I'd rather strongly argue that no matter what is the answer to this \n> > question, we _HAVE TO_ unsetenv() GIT_CONFIG at some stage, otherwise \n> > no .git/config will be written.\n> \n> Why should .git/config get written?\n\nBecause the user asked for a clone, where she reasonably expects a git \nrepository with all the [core] and the initial [remote \"origin\"] settings \nto be written as it should be, _even if_ setting the config to somewhere \nelse?  Hmm?\n\nIMITCNVHO it would be a serious mistake to write the config somewhere else \nwith \"clone\".\n\nIf that still does not convince you, \"git init\" also writes to \n\".git/config\" regardless of the user's (possibly bogus) GIT_CONFIG.\n\nIt is just such a basic thing that you must _not_ use GIT_CONFIG for \nwriting with git clone or git init.\n\nCiao,\nDscho\n"},{"id":"81693","messageId":"7vabh390sc.fsf@gitster.siamese.dyndns.org","threadId":"14180","inReplyTo":"alpine.LNX.1.00.0806291821520.19665@iabervon.org","subject":"Re: [PATCH 1/2] clone: respect the settings in $HOME/.gitconfig and /etc/gitconfig","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-06-30T01:20:03Z","receivedAt":"2008-06-30T01:20:03Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow <barkalow@iabervon.org> writes:\n\n> ... In any case, I don't think \"git clone\" is at \n> all special with respect to GIT_CONFIG.\n\nI think \"git init\" and \"git clone\" are very special with respect to\nGIT_CONFIG.\n\n * When \"init\" is run to create a new repository and initialize it, the\n   user would want the initial set of configuration populated in the\n   configuration file _for that repository_.  There however may be some\n   customization that affects the way how \"init\" operates, which might be\n   taken from $HOME/.gitconfig.  The meaning of GIT_CONFIG can get fuzzy\n   here.  Possibilities:\n\n   (1) Instead of $HOME/.gitconfig (or /etc/gitconfig), the user might\n       want such customizations to be read from the file specified by\n       GIT_CONFIG.  But the user wants to make the resulting new\n       repository usable without any custom GIT_CONFIG set (i.e. its\n       $GIT_DIR/config will be the place the configuration is written).\n\n   (2) The user may want to create a new repository that cannot be used\n       with GIT_CONFIG (for some strange reason), i.e. no $GIT_DIR/config\n       for the repository, and GIT_CONFIG is used to specify where that\n       separate configuration file for the new repository is.  The way\n       \"init\" operates does not come from that configuration file that is\n       to be created but from elsewhere.\n\n * When \"clone\" is run, the same confusion as initializing \"init\" applies.\n   In addition, custom GIT_CONFIG to read customizations for behaviour of\n   \"init\" and \"fetch\" that is done internally by \"clone\" would play larger\n   role.\n\n * When \"init\" is run to reinitialize an existing repository, it is not\n   special in any way with respect to GIT_CONFIG, compared to other\n   commands.  The GIT_CONFIG names the configuration for that existing\n   repository, so we read from it and write to it.\n\nI personally think the case (2) is a very narrow special case that I do\nnot think of any sane reason to even wanting to do so.  IOW, \"you _could_\ninterpret the presense of GIT_CONFIG that the user may want to do so, but\nwhy?\"  (1) is also probably not very sensible but it makes more sense.\n\nI think Dscho's original patch would support the semantics (1) and it is\nprobably much saner than (2) which is your version does (if I am reading\nthe two patches correctly).\n"},{"id":"81699","messageId":"alpine.LNX.1.00.0806292047100.19665@iabervon.org","threadId":"14180","inReplyTo":"alpine.DEB.1.00.0806300134200.9925@racer","subject":"Re: [PATCH 1/2] clone: respect the settings in $HOME/.gitconfig and /etc/gitconfig","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-06-30T01:54:11Z","receivedAt":"2008-06-30T01:54:11Z","isPatch":true,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Mon, 30 Jun 2008, Johannes Schindelin wrote:\n\n> Hi,\n> \n> On Sun, 29 Jun 2008, Daniel Barkalow wrote:\n> \n> > On Sun, 29 Jun 2008, Johannes Schindelin wrote:\n> > \n> > > On Sun, 29 Jun 2008, Daniel Barkalow wrote:\n> > > \n> > > > Did we even make a commitment on whether:\n> > > > \n> > > > GIT_CONFIG=foo git clone bar\n> > > > \n> > > > must ignore the environment variable, or simply doesn't necessarily \n> > > > obey it?\n> > > \n> > > I'd rather strongly argue that no matter what is the answer to this \n> > > question, we _HAVE TO_ unsetenv() GIT_CONFIG at some stage, otherwise \n> > > no .git/config will be written.\n> > \n> > Why should .git/config get written?\n> \n> Because the user asked for a clone, where she reasonably expects a git \n> repository with all the [core] and the initial [remote \"origin\"] settings \n> to be written as it should be, _even if_ setting the config to somewhere \n> else?  Hmm?\n\nBut those should be written to the location of the config file, where \nsubsequent commands will find them, which is $GIT_CONFIG if it's set and \ngit commands in general use it. I mean:\n\n$ export GIT_CONFIG=/home/barkalow/something\n$ git clone git://git.kernel.org/pub/scm/git/git.git\n$ cd git\n$ git fetch\nfatal: 'origin': unable to chdir or not a git archive\nfatal: The remote end hung up unexpectedly\n\n(because \"git clone\" currently ignores GIT_CONFIG, but \"git fetch\" \ndoesn't, so it can't find the initial [remote \"origin\"] settings).\n\n> IMITCNVHO it would be a serious mistake to write the config somewhere else \n> with \"clone\".\n> \n> If that still does not convince you, \"git init\" also writes to \n> \".git/config\" regardless of the user's (possibly bogus) GIT_CONFIG.\n\nNo, \"git init\" has always written to GIT_CONFIG. In fact, git-clone.sh \nused to depend on it writing to GIT_CONFIG, which is how it caused the \nconfig file to be written into the new clone.\n\n> It is just such a basic thing that you must _not_ use GIT_CONFIG for \n> writing with git clone or git init.\n\nSurely, then, you must not use GIT_CONFIG when reading the options that \ngit clone writes? But I think this reduces to \"you must not use GIT_CONFIG \nwhen using a repository\", which pretty much leaves \"git config\". And I \nthink it's only ever *useful* for \"git config\" anyway.\n\nIt doesn't make much sense to ensure that \"git clone\" works if you have \nGIT_CONFIG set when nothing else works in that situation. I still don't \nknow what setting it is good for (and the commit that introduced it \nexplained what it did, but not why), but I think we should be consistant \nabout whether or not it affects where git expects configuration to be.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"81700","messageId":"alpine.LNX.1.00.0806292157540.19665@iabervon.org","threadId":"14180","inReplyTo":"7vabh390sc.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH 1/2] clone: respect the settings in $HOME/.gitconfig and /etc/gitconfig","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-06-30T02:21:21Z","receivedAt":"2008-06-30T02:21:21Z","isPatch":true,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sun, 29 Jun 2008, Junio C Hamano wrote:\n\n> Daniel Barkalow <barkalow@iabervon.org> writes:\n> \n> > ... In any case, I don't think \"git clone\" is at \n> > all special with respect to GIT_CONFIG.\n> \n> I think \"git init\" and \"git clone\" are very special with respect to\n> GIT_CONFIG.\n> \n>  * When \"init\" is run to create a new repository and initialize it, the\n>    user would want the initial set of configuration populated in the\n>    configuration file _for that repository_.  There however may be some\n>    customization that affects the way how \"init\" operates, which might be\n>    taken from $HOME/.gitconfig.  The meaning of GIT_CONFIG can get fuzzy\n>    here.  Possibilities:\n> \n>    (1) Instead of $HOME/.gitconfig (or /etc/gitconfig), the user might\n>        want such customizations to be read from the file specified by\n>        GIT_CONFIG.  But the user wants to make the resulting new\n>        repository usable without any custom GIT_CONFIG set (i.e. its\n>        $GIT_DIR/config will be the place the configuration is written).\n> \n>    (2) The user may want to create a new repository that cannot be used\n>        with GIT_CONFIG (for some strange reason), i.e. no $GIT_DIR/config\n>        for the repository, and GIT_CONFIG is used to specify where that\n>        separate configuration file for the new repository is.  The way\n>        \"init\" operates does not come from that configuration file that is\n>        to be created but from elsewhere.\n> \n>  * When \"clone\" is run, the same confusion as initializing \"init\" applies.\n>    In addition, custom GIT_CONFIG to read customizations for behaviour of\n>    \"init\" and \"fetch\" that is done internally by \"clone\" would play larger\n>    role.\n> \n>  * When \"init\" is run to reinitialize an existing repository, it is not\n>    special in any way with respect to GIT_CONFIG, compared to other\n>    commands.  The GIT_CONFIG names the configuration for that existing\n>    repository, so we read from it and write to it.\n> \n> I personally think the case (2) is a very narrow special case that I do\n> not think of any sane reason to even wanting to do so.  IOW, \"you _could_\n> interpret the presense of GIT_CONFIG that the user may want to do so, but\n> why?\"  (1) is also probably not very sensible but it makes more sense.\n\nActually, (1) has never worked for either clone or init. Init always \nobeyed GIT_CONFIG as for where it put the output (in fact git-clone.sh \nused GIT_CONFIG to cause git-init to write to the created repo, IIRC). \nClone always replaced GIT_CONFIG with the destination location before it \nread any configuration, so it wouldn't see configuration that was in the \nuser's GIT_CONFIG (or in any pre-existing config file at all). \nHistorically, these commands don't support (1) and aren't consistant with \neach other.\n\nI think it would make sense if there were some way to provide custom \nconfiguration to a particular invocation of \"git clone\", but GIT_CONFIG as \ncurrently handled by config.c can't do it.\n\n> I think Dscho's original patch would support the semantics (1) and it is\n> probably much saner than (2) which is your version does (if I am reading\n> the two patches correctly).\n\nMy patch makes \"git clone\" do what \"git init; git remote; git fetch\" do \nwith respect to GIT_CONFIG. I don't think this behavior is really useful \nfor any of those programs or for the combination, but at least having them \nmatch would be consistant. I think the sensible thing would be for \nconfig.c to always write to git_path(\"config\") (or a variable used by \n\"git config\"), and read: git_path(\"config\"), $GIT_CONFIG, ~/.gitconfig, \n/etc/gitconfig (in order of decreasing precedence); and further have \nbuiltin-config.c set the \"file to write to\" variable based on $GIT_CONFIG \nor \"--file\", \"--global\", or \"--system\".\n\nBut I don't really understand what the purpose of the feature was in the \nfirst place, aside from the narrow case of being able to read and write \nfiles that use the config file format with \"git config\".\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"81707","messageId":"alpine.LNX.1.00.0806292320300.19665@iabervon.org","threadId":"14180","inReplyTo":"7vabh390sc.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH 1/2] clone: respect the settings in $HOME/.gitconfig and /etc/gitconfig","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-06-30T03:47:50Z","receivedAt":"2008-06-30T03:47:50Z","isPatch":true,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sun, 29 Jun 2008, Junio C Hamano wrote:\n\n> Daniel Barkalow <barkalow@iabervon.org> writes:\n> \n> > ... In any case, I don't think \"git clone\" is at \n> > all special with respect to GIT_CONFIG.\n> \n> I think \"git init\" and \"git clone\" are very special with respect to\n> GIT_CONFIG.\n> \n>  * When \"init\" is run to create a new repository and initialize it, the\n>    user would want the initial set of configuration populated in the\n>    configuration file _for that repository_.  There however may be some\n>    customization that affects the way how \"init\" operates, which might be\n>    taken from $HOME/.gitconfig.  The meaning of GIT_CONFIG can get fuzzy\n>    here.  Possibilities:\n> \n>    (1) Instead of $HOME/.gitconfig (or /etc/gitconfig), the user might\n>        want such customizations to be read from the file specified by\n>        GIT_CONFIG.  But the user wants to make the resulting new\n>        repository usable without any custom GIT_CONFIG set (i.e. its\n>        $GIT_DIR/config will be the place the configuration is written).\n> \n>    (2) The user may want to create a new repository that cannot be used\n>        with GIT_CONFIG (for some strange reason), i.e. no $GIT_DIR/config\n>        for the repository, and GIT_CONFIG is used to specify where that\n>        separate configuration file for the new repository is.  The way\n>        \"init\" operates does not come from that configuration file that is\n>        to be created but from elsewhere.\n> \n>  * When \"clone\" is run, the same confusion as initializing \"init\" applies.\n>    In addition, custom GIT_CONFIG to read customizations for behaviour of\n>    \"init\" and \"fetch\" that is done internally by \"clone\" would play larger\n>    role.\n> \n>  * When \"init\" is run to reinitialize an existing repository, it is not\n>    special in any way with respect to GIT_CONFIG, compared to other\n>    commands.  The GIT_CONFIG names the configuration for that existing\n>    repository, so we read from it and write to it.\n> \n> I personally think the case (2) is a very narrow special case that I do\n> not think of any sane reason to even wanting to do so.  IOW, \"you _could_\n> interpret the presense of GIT_CONFIG that the user may want to do so, but\n> why?\"  (1) is also probably not very sensible but it makes more sense.\n> \n> I think Dscho's original patch would support the semantics (1) and it is\n> probably much saner than (2) which is your version does (if I am reading\n> the two patches correctly).\n\nA bit more information on this. There are 3 possible states for \nGIT_CONFIG:\n\n (1) Not set; things work normally\n\n (2) Set to \".git/config\"; things work normally except that no global or \n     system config is used\n\n (3) Set to something else; anything expecting to read or write \n     configuration related to the repo will misbehave\n\nHistorically, clone worked entirely in state (2) regardless of what the \nuser asked for. Everything else left it how the user had it. Dscho's patch \nchanges it to initialize the repo in state (2) and fetch in state (1), \nstill ignoring what the user set. My patch changes it to leave it how the \nuser has it.\n\nNow, clone writes to the config file before reading any configuration, so, \nif it's going to write to \".git/config\" instead of $GIT_CONFIG, it can't \nread from $GIT_CONFIG either. So there's no way (outside of redesigning \nconfig.c) to make GIT_CONFIG useful for \"clone\" in particular. Other \ncommands don't clear it, so they just misbehave if it's set. We can be \npretty sure, therefore, that users will put it either in (1) or (if they \nwant GIT_CONFIG_NO_GLOBAL and don't know about it and aren't worried about \n\"clone\") in (2). So the practical difference between my patch and Dscho's \nis that, with mine, ~/.gitconfig would affect the initialization step if \nit actually used any config settings.\n\nIf you want anything more clever to happen, that requires config.c \nchanges of some sort to provide a state where it reads some additional \nfile but writes the repo's usual one, and probably *also* *my* patch, so \nthat clone doesn't blow away the user's setting before config.c gets it.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"81718","messageId":"7vwsk730mm.fsf@gitster.siamese.dyndns.org","threadId":"14180","inReplyTo":"alpine.DEB.1.00.0806292248160.9925@racer","subject":"Re: [PATCH 1/2] clone: respect the settings in $HOME/.gitconfig and /etc/gitconfig","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-06-30T06:20:01Z","receivedAt":"2008-06-30T06:20:01Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> On Sun, 29 Jun 2008, Daniel Barkalow wrote:\n>\n>> Did we even make a commitment on whether:\n>> \n>> GIT_CONFIG=foo git clone bar\n>> \n>> must ignore the environment variable, or simply doesn't necessarily obey \n>> it?\n>\n> I'd rather strongly argue that no matter what is the answer to this \n> question, we _HAVE TO_ unsetenv() GIT_CONFIG at some stage, otherwise no \n> .git/config will be written.\n>\n> So, this is a NACK on your patch.\n\nTrue.  We are creating the config file for the new repository, so the\ninitial setenv() would make sense.  We _could_ save away end user's\nGIT_CONFIG and restore it where you unsetenv() in your patch, but I do not\nthink it would buy us anything other than \"be consistent with other\nprograms that misbehave when end user has GIT_CONFIG\".  \n\nHonestly, GIT_CONFIG is purely for scripts like git-svn that muck with\nfiles that are in the config format to have a way to make sure that they\naccess the file they intend to, and being able to use GIT_CONFIG to keep\ngit programs from reading from $HOME/.gitconfig is primarily for giving\nour test scripts repeatable environment, nothing more.\n\nI think ignoring end-user GIT_CONFIG like this patch does, instead of\ndoing random nonsense, would be a good bugfix for \"git clone\".\n"},{"id":"81719","messageId":"7vskuv30e6.fsf@gitster.siamese.dyndns.org","threadId":"14180","inReplyTo":"7vwsk730mm.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH 1/2] clone: respect the settings in $HOME/.gitconfig and /etc/gitconfig","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-06-30T06:25:05Z","receivedAt":"2008-06-30T06:25:05Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Honestly, GIT_CONFIG is purely for scripts like git-svn that muck with\n> files that are in the config format to have a way to make sure that they\n> access the file they intend to, and being able to use GIT_CONFIG to keep\n> git programs from reading from $HOME/.gitconfig is primarily for giving\n> our test scripts repeatable environment, nothing more.\n>\n> I think ignoring end-user GIT_CONFIG like this patch does, instead of\n> doing random nonsense, would be a good bugfix for \"git clone\".\n\nOf course, that would have downsides as well.  Now git-clone tests cannot\nbe sanely written without setting $HOME to somewhere stable; otherwise\nthey can be randomly affected by buggy $HOME/.gitconfig files the end user\nmay have.\n"},{"id":"81721","messageId":"20080630064031.GA30600@sigill.intra.peff.net","threadId":"14180","inReplyTo":"7vskuv30e6.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH 1/2] clone: respect the settings in $HOME/.gitconfig and /etc/gitconfig","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-06-30T06:40:32Z","receivedAt":"2008-06-30T06:40:32Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Jun 29, 2008 at 11:25:05PM -0700, Junio C Hamano wrote:\n\n> > Honestly, GIT_CONFIG is purely for scripts like git-svn that muck with\n> > files that are in the config format to have a way to make sure that they\n> > access the file they intend to, and being able to use GIT_CONFIG to keep\n> > git programs from reading from $HOME/.gitconfig is primarily for giving\n> > our test scripts repeatable environment, nothing more.\n[...]\n> Of course, that would have downsides as well.  Now git-clone tests cannot\n> be sanely written without setting $HOME to somewhere stable; otherwise\n> they can be randomly affected by buggy $HOME/.gitconfig files the end user\n> may have.\n\nI thought we went through all of this before, and it led to 8bfa6bd6.\nThe test scripts set GIT_CONFIG_NOSYSTEM and GIT_CONFIG_NOGLOBAL to\nachieve the same suppression effect.\n\n-Peff\n"},{"id":"81722","messageId":"7vod5j2zi1.fsf@gitster.siamese.dyndns.org","threadId":"14180","inReplyTo":"20080630064031.GA30600@sigill.intra.peff.net","subject":"Re: [PATCH 1/2] clone: respect the settings in $HOME/.gitconfig and /etc/gitconfig","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-06-30T06:44:22Z","receivedAt":"2008-06-30T06:44:22Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n>> Of course, that would have downsides as well.  Now git-clone tests cannot\n>> be sanely written without setting $HOME to somewhere stable; otherwise\n>> they can be randomly affected by buggy $HOME/.gitconfig files the end user\n>> may have.\n>\n> I thought we went through all of this before, and it led to 8bfa6bd6.\n> The test scripts set GIT_CONFIG_NOSYSTEM and GIT_CONFIG_NOGLOBAL to\n> achieve the same suppression effect.\n\nAh, thanks.  Actually I was scratching my head trying to figure out why it\ndoes not break after I wrote the above ;-)\n"},{"id":"81745","messageId":"alpine.DEB.1.00.0806301236110.9925@racer","threadId":"14180","inReplyTo":"7vwsk730mm.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH 1/2] clone: respect the settings in $HOME/.gitconfig and /etc/gitconfig","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-06-30T11:37:45Z","receivedAt":"2008-06-30T11:37:45Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 29 Jun 2008, Junio C Hamano wrote:\n\n> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n> \n> > On Sun, 29 Jun 2008, Daniel Barkalow wrote:\n> >\n> >> Did we even make a commitment on whether:\n> >> \n> >> GIT_CONFIG=foo git clone bar\n> >> \n> >> must ignore the environment variable, or simply doesn't necessarily \n> >> obey it?\n> >\n> > I'd rather strongly argue that no matter what is the answer to this \n> > question, we _HAVE TO_ unsetenv() GIT_CONFIG at some stage, otherwise \n> > no .git/config will be written.\n> >\n> > So, this is a NACK on your patch.\n> \n> True.  We are creating the config file for the new repository, so the\n> initial setenv() would make sense.  We _could_ save away end user's\n> GIT_CONFIG and restore it where you unsetenv() in your patch,\n\nNo.  That would break again, since then,\n\n- $HOME/.gitconfig would be ignored again (which was the single issue my \n  patch addressed), and\n- the remote information would be written into the wrong file.\n\nCiao,\nDscho\n"},{"id":"81748","messageId":"alpine.DEB.1.00.0806301233560.9925@racer","threadId":"14180","inReplyTo":"alpine.LNX.1.00.0806292320300.19665@iabervon.org","subject":"Re: [PATCH 1/2] clone: respect the settings in $HOME/.gitconfig and /etc/gitconfig","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-06-30T11:57:16Z","receivedAt":"2008-06-30T11:57:16Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 29 Jun 2008, Daniel Barkalow wrote:\n\n> Now, clone writes to the config file before reading any configuration, so, \n> if it's going to write to \".git/config\" instead of $GIT_CONFIG, it can't \n> read from $GIT_CONFIG either. So there's no way (outside of redesigning \n> config.c) to make GIT_CONFIG useful for \"clone\" in particular.\n\nExcept you could read the config _before_ writing.\n\nOr you could enhance (not redesign, as you suggest) config.c thusly:\n\n-- snip --\ndiff --git a/cache.h b/cache.h\nindex 871f6c1..f3ea997 100644\n--- a/cache.h\n+++ b/cache.h\n@@ -742,6 +742,7 @@ extern int git_config_bool(const char *, const char *);\n extern int git_config_string(const char **, const char *, const char *);\n extern int git_config_set(const char *, const char *);\n extern int git_config_set_multivar(const char *, const char *, const char *, int);\n+extern int git_config_set_multivar_in_file(const char *, const char *, const char *, int, const char *);\n extern int git_config_rename_section(const char *, const char *);\n extern const char *git_etc_gitconfig(void);\n extern int check_repository_format_version(const char *var, const char *value, void *cb);\ndiff --git a/config.c b/config.c\nindex 58749bf..41a35eb 100644\n--- a/config.c\n+++ b/config.c\n@@ -863,23 +863,31 @@ int git_config_set(const char* key, const char* value)\n  * - the config file is removed and the lock file rename()d to it.\n  *\n  */\n-int git_config_set_multivar(const char* key, const char* value,\n-\tconst char* value_regex, int multi_replace)\n+int git_config_set_multivar(const char *key, const char *value,\n+\tconst char *value_regex, int multi_replace)\n+{\n+\treturn git_config_set_multivar_in_file(key, value, value_regex,\n+\t\tmulti_replace, NULL);\n+}\n+\n+int git_config_set_multivar_in_file(const char *key, const char *value,\n+\tconst char *value_regex, int multi_replace, const char *config_filename)\n {\n \tint i, dot;\n \tint fd = -1, in_fd;\n \tint ret;\n-\tchar* config_filename;\n+\tchar *filename;\n \tstruct lock_file *lock = NULL;\n \tconst char* last_dot = strrchr(key, '.');\n \n-\tconfig_filename = getenv(CONFIG_ENVIRONMENT);\n+\tif (!config_filename)\n+\t\tconfig_filename = getenv(CONFIG_ENVIRONMENT);\n \tif (!config_filename) {\n \t\tconfig_filename = getenv(CONFIG_LOCAL_ENVIRONMENT);\n \t\tif (!config_filename)\n-\t\t\tconfig_filename  = git_path(\"config\");\n+\t\t\tconfig_filename =\n+\t\t\t\tfilename = xstrdup(git_path(\"config\"));\n \t}\n-\tconfig_filename = xstrdup(config_filename);\n \n \t/*\n \t * Since \"key\" actually contains the section name and the real\n@@ -1091,7 +1099,8 @@ int git_config_set_multivar(const char* key, const char* value,\n out_free:\n \tif (lock)\n \t\trollback_lock_file(lock);\n-\tfree(config_filename);\n+\tif (filename)\n+\t\tfree(filename);\n \treturn ret;\n \n write_err_out:\n-- snap --\n\n... and then have something like\n\n        config_filename = xstrdup(mkpath(\"%s/config\", git_dir));\n\n        if (safe_create_leading_directories_const(git_dir) < 0)\n                die(\"could not create leading directories of '%s'\", git_dir);\n        set_git_dir(make_absolute_path(git_dir));\n\n\t[...]\n\n\tif (option_bare) {\n                strcpy(branch_top, \"refs/heads/\");\n\n                git_config_set_multivar_in_file(\"core.bare\", \"true\",\n\t\t\tNULL, 0, config_filename);\n\n\t[...]\n\nOf course, you would also have to teach init_db() to use this filename.\n\nBut frankly, I do not see the use of your \"narrow\" special case.  And as I \nstated in another thread, I am pretty opposed to crossing bridges that are \nmiles (or an eternity) away.\n\nSo unless you present me with a sensible scenario where your \"respect \nGIT_CONFIG for _reading_ in GIT_CONFIG=... git clone\" makes sense, there \nis nothing to see here, please move along.\n\nCiao,\nDscho\n"},{"id":"81758","messageId":"alpine.LNX.1.00.0806301227320.19665@iabervon.org","threadId":"14180","inReplyTo":"alpine.DEB.1.00.0806301233560.9925@racer","subject":"Re: [PATCH 1/2] clone: respect the settings in $HOME/.gitconfig and /etc/gitconfig","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-06-30T16:47:04Z","receivedAt":"2008-06-30T16:47:04Z","isPatch":true,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Mon, 30 Jun 2008, Johannes Schindelin wrote:\n\n> Hi,\n> \n> On Sun, 29 Jun 2008, Daniel Barkalow wrote:\n> \n> > Now, clone writes to the config file before reading any configuration, so, \n> > if it's going to write to \".git/config\" instead of $GIT_CONFIG, it can't \n> > read from $GIT_CONFIG either. So there's no way (outside of redesigning \n> > config.c) to make GIT_CONFIG useful for \"clone\" in particular.\n> \n> Except you could read the config _before_ writing.\n> \n> Or you could enhance (not redesign, as you suggest) config.c thusly:\n> \n> -- snip --\n> diff --git a/cache.h b/cache.h\n> index 871f6c1..f3ea997 100644\n> --- a/cache.h\n> +++ b/cache.h\n> @@ -742,6 +742,7 @@ extern int git_config_bool(const char *, const char *);\n>  extern int git_config_string(const char **, const char *, const char *);\n>  extern int git_config_set(const char *, const char *);\n>  extern int git_config_set_multivar(const char *, const char *, const char *, int);\n> +extern int git_config_set_multivar_in_file(const char *, const char *, const char *, int, const char *);\n>  extern int git_config_rename_section(const char *, const char *);\n>  extern const char *git_etc_gitconfig(void);\n>  extern int check_repository_format_version(const char *var, const char *value, void *cb);\n> diff --git a/config.c b/config.c\n> index 58749bf..41a35eb 100644\n> --- a/config.c\n> +++ b/config.c\n> @@ -863,23 +863,31 @@ int git_config_set(const char* key, const char* value)\n>   * - the config file is removed and the lock file rename()d to it.\n>   *\n>   */\n> -int git_config_set_multivar(const char* key, const char* value,\n> -\tconst char* value_regex, int multi_replace)\n> +int git_config_set_multivar(const char *key, const char *value,\n> +\tconst char *value_regex, int multi_replace)\n> +{\n> +\treturn git_config_set_multivar_in_file(key, value, value_regex,\n> +\t\tmulti_replace, NULL);\n> +}\n> +\n> +int git_config_set_multivar_in_file(const char *key, const char *value,\n> +\tconst char *value_regex, int multi_replace, const char *config_filename)\n>  {\n>  \tint i, dot;\n>  \tint fd = -1, in_fd;\n>  \tint ret;\n> -\tchar* config_filename;\n> +\tchar *filename;\n>  \tstruct lock_file *lock = NULL;\n>  \tconst char* last_dot = strrchr(key, '.');\n>  \n> -\tconfig_filename = getenv(CONFIG_ENVIRONMENT);\n> +\tif (!config_filename)\n> +\t\tconfig_filename = getenv(CONFIG_ENVIRONMENT);\n>  \tif (!config_filename) {\n>  \t\tconfig_filename = getenv(CONFIG_LOCAL_ENVIRONMENT);\n>  \t\tif (!config_filename)\n> -\t\t\tconfig_filename  = git_path(\"config\");\n> +\t\t\tconfig_filename =\n> +\t\t\t\tfilename = xstrdup(git_path(\"config\"));\n>  \t}\n> -\tconfig_filename = xstrdup(config_filename);\n>  \n>  \t/*\n>  \t * Since \"key\" actually contains the section name and the real\n> @@ -1091,7 +1099,8 @@ int git_config_set_multivar(const char* key, const char* value,\n>  out_free:\n>  \tif (lock)\n>  \t\trollback_lock_file(lock);\n> -\tfree(config_filename);\n> +\tif (filename)\n> +\t\tfree(filename);\n>  \treturn ret;\n>  \n>  write_err_out:\n> -- snap --\n> \n> ... and then have something like\n> \n>         config_filename = xstrdup(mkpath(\"%s/config\", git_dir));\n> \n>         if (safe_create_leading_directories_const(git_dir) < 0)\n>                 die(\"could not create leading directories of '%s'\", git_dir);\n>         set_git_dir(make_absolute_path(git_dir));\n> \n> \t[...]\n> \n> \tif (option_bare) {\n>                 strcpy(branch_top, \"refs/heads/\");\n> \n>                 git_config_set_multivar_in_file(\"core.bare\", \"true\",\n> \t\t\tNULL, 0, config_filename);\n> \n> \t[...]\n> \n> Of course, you would also have to teach init_db() to use this filename.\n> \n> But frankly, I do not see the use of your \"narrow\" special case.  And as I \n> stated in another thread, I am pretty opposed to crossing bridges that are \n> miles (or an eternity) away.\n> \n> So unless you present me with a sensible scenario where your \"respect \n> GIT_CONFIG for _reading_ in GIT_CONFIG=... git clone\" makes sense, there \n> is nothing to see here, please move along.\n\nI haven't been able to find a sensible scenario for paying attention to \nGIT_CONFIG at all, except for backwards compatibility in builtin-config.c; \nI'd been going on the assumption that there was a sensible scenario for \nhaving it in the first place, and that \"git clone\" wouldn't be any \ndifferent from \"git init\", \"git remote\", or \"git fetch\". \n\nBut nobody seems to have any reason for GIT_CONFIG to exist outside of the \n\"git config\" command-line and environment parsing, so I posted a patch to \nrip it out of the general code, so \"git clone\" doesn't have to deal with \nit at all.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"}]}