# [PATCH 2/2] clone: pass the remote name to remote_get 3 messages from 2010-03-21 to 2010-03-21. Participants: Sverre Rabbelier. Thread: https://gitlist.dev/t/23127 ## Sverre Rabbelier, 2010-03-21 20:19 Subject: [PATCH 1/2] Move setup_reference to after writing the config file Message-ID: <1269202789-8833-1-git-send-email-srabbelier@gmail.com> URL: https://gitlist.dev/e/1269202789-8833-1-git-send-email-srabbelier%40gmail.com ``` Currently setup_reference calls remote_get before the remote is added to the config file. This will result in an improperly configured remote (in memory) if later on remote_get is called with an argument that is not equal to the initial remote_get call in setup_reference. Fix this by delaying the remote_get call until after the remote has been added to the config file. --- It is also possible to split setup_reference so that the part that calls remote_get is where the entire setup_referene call is moved to now, this also works, and results in a far simpler patch. This change is required for the next patch. builtin/clone.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/builtin/clone.c b/builtin/clone.c index 05f8fb4..f878563 100644 --- a/builtin/clone.c +++ b/builtin/clone.c @@ -470,9 +470,6 @@ int cmd_clone(int argc, const char **argv, const char *prefix) */ unsetenv(CONFIG_ENVIRONMENT); - if (option_reference) - setup_reference(git_dir); - git_config(git_default_config, NULL); if (option_bare) { @@ -504,6 +501,9 @@ int cmd_clone(int argc, const char **argv, const char *prefix) strbuf_reset(&key); } + if (option_reference) + setup_reference(git_dir); + fetch_pattern = value.buf; refspec = parse_fetch_refspec(1, &fetch_pattern); -- 1.7.0.2.325.g634e5 ``` ## Sverre Rabbelier, 2010-03-21 20:19 Subject: [PATCH 2/2] clone: pass the remote name to remote_get Message-ID: <1269202789-8833-2-git-send-email-srabbelier@gmail.com> URL: https://gitlist.dev/e/1269202789-8833-2-git-send-email-srabbelier%40gmail.com In-Reply-To: <1269202789-8833-1-git-send-email-srabbelier@gmail.com> ``` Currently when using a remote helper to clone a repository, the remote helper will be passed the url of the target repository as first argument (which represents the name of the remote). This name is extracted from transport->remote->name, which is set by builtin/clone.c when it calls remote_get with argv[0] as argument. Fix this by passing the name remote will be set up as instead. --- I've spent quite a few hours trying to figure out why this broke t5700, so I would appreciate feedback from those with more knowledge about hardlinking and clone/fetch in general as to whether this couild cause any problems. builtin/clone.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/builtin/clone.c b/builtin/clone.c index f878563..068d61f 100644 --- a/builtin/clone.c +++ b/builtin/clone.c @@ -513,7 +513,7 @@ int cmd_clone(int argc, const char **argv, const char *prefix) refs = clone_local(path, git_dir); mapped_refs = wanted_peer_refs(refs, refspec); } else { - struct remote *remote = remote_get(argv[0]); + struct remote *remote = remote_get(option_origin); transport = transport_get(remote, remote->url[0]); if (!transport->get_refs_list || !transport->fetch) -- 1.7.0.2.325.g634e5 ``` ## Sverre Rabbelier, 2010-03-21 23:27 Subject: Re: [PATCH 2/2] clone: pass the remote name to remote_get Message-ID: URL: https://gitlist.dev/e/fabb9a1e1003211627q7ea75194j941fe9ae23f77b66%40mail.gmail.com In-Reply-To: <1269202789-8833-2-git-send-email-srabbelier@gmail.com> ``` Heya, On Sun, Mar 21, 2010 at 21:19, Sverre Rabbelier wrote: > Currently when using a remote helper to clone a repository, the > remote helper will be passed the url of the target repository as > first argument (which represents the name of the remote). This name > is extracted from transport->remote->name, which is set by > builtin/clone.c when it calls remote_get with argv[0] as argument. > > Fix this by passing the name remote will be set up as instead. Ah, I forgot a sign-off it seems. Also, these two patches were a bit more involved before (I didn't arrive at their current form for quite a few hours), so I guess it could makes sense to just squash them into one patch. Whichever is preferable. -- Cheers, Sverre Rabbelier ```