{"thread":{"id":"15949","subject":"[PATCH] git-fetch should not strip off \".git\" extension","startedAt":"2008-10-18T11:59:41Z","lastAt":"2008-10-22T11:50:24Z","messageCount":13,"participants":["Leo Razoumov","Andreas Ericsson","Junio C Hamano","Alex Riesen"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"93356","messageId":"ee2a733e0810180459m5fd20365s3c27bea5c1f3f704@mail.gmail.com","threadId":"15949","inReplyTo":null,"subject":"[PATCH] git-fetch should not strip off \".git\" extension","fromName":"Leo Razoumov","fromEmail":"slonik.az@gmail.com","sentAt":"2008-10-18T11:59:41Z","receivedAt":"2008-10-18T11:59:41Z","isPatch":true,"sender":{"key":"slonik.az@gmail.com","avatar":null},"body":"When source git repository has extension \".git\" like in \"MyRepo.git\"\n\"git fetch\" will drop \".git\" extension and refer to it as \"MyRepo\".\n\nExample:\n\nsh$ git fetch -v ../MyRepo.git master\nFrom ../MyRepo\n * branch master -> FETCH_HEAD\n\nsh$ cat .git/FETCH_HEAD\n6eb10bd105f2ef7f64c595100c0a850c5b3cfeb9 branch 'master' of ../MyRepo\n\nPlease, note that \"git fetch\" writes \"../MyRepo\" instead of \"../MyRepo.git\"\n\nMy workflow makes it convenient to have two distinct repositories\n(1) \"MyRepo\" => where I work daily (WIP)\n(2) \"MyRepo.git\" => --bare repository accessible to others. \"MyRepo\"\npushes ready changes to \"MyRepo.git\"\nDropping \".git\" extension causes confusion between these two quite\nsimilarly named repositories.\n\nThis problem can be easily solved by the patch below that removes the\ncode that strips off \".git\" extension.\n\n--Leo--\n\n----8<-------------------\n\n builtin-fetch--tool.c | 2 --\n builtin-fetch.c | 2 --\n 2 files changed, 0 insertions(+), 4 deletions(-)\n\ndiff --git a/builtin-fetch--tool.c b/builtin-fetch--tool.c\nindex 7460ab7..5d0b95f 100644\n--- a/builtin-fetch--tool.c\n+++ b/builtin-fetch--tool.c\n@@ -160,8 +160,6 @@ static int append_fetch_head(FILE *fp,\n \tfor (i = remote_len - 1; remote[i] == '/' && 0 <= i; i--)\n \t\t;\n \tremote_len = i + 1;\n-\tif (4 < i && !strncmp(\".git\", remote + i - 3, 4))\n-\t\tremote_len = i - 3;\n\n \tnote_len = 0;\n \tif (*what) {\ndiff --git a/builtin-fetch.c b/builtin-fetch.c\nindex ee93d3a..28123a5 100644\n--- a/builtin-fetch.c\n+++ b/builtin-fetch.c\n@@ -348,8 +348,6 @@ static int store_updated_refs(const char *url,\nconst char *remote_name,\n \t\tfor (i = url_len - 1; url[i] == '/' && 0 <= i; i--)\n \t\t\t;\n \t\turl_len = i + 1;\n-\t\tif (4 < i && !strncmp(\".git\", url + i - 3, 4))\n-\t\t\turl_len = i - 3;\n\n \t\tnote_len = 0;\n \t\tif (*what) {\n"},{"id":"93490","messageId":"48FC5F1B.1050608@op5.se","threadId":"15949","inReplyTo":"ee2a733e0810180459m5fd20365s3c27bea5c1f3f704@mail.gmail.com","subject":"Re: [PATCH] git-fetch should not strip off \".git\" extension","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2008-10-20T10:36:11Z","receivedAt":"2008-10-20T10:36:11Z","isPatch":true,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Leo Razoumov wrote:\n> When source git repository has extension \".git\" like in \"MyRepo.git\"\n> \"git fetch\" will drop \".git\" extension and refer to it as \"MyRepo\".\n> \n> Example:\n> \n> sh$ git fetch -v ../MyRepo.git master\n> From ../MyRepo\n> * branch master -> FETCH_HEAD\n> \n> sh$ cat .git/FETCH_HEAD\n> 6eb10bd105f2ef7f64c595100c0a850c5b3cfeb9 branch 'master' of ../MyRepo\n> \n> Please, note that \"git fetch\" writes \"../MyRepo\" instead of \"../MyRepo.git\"\n> \n> My workflow makes it convenient to have two distinct repositories\n> (1) \"MyRepo\" => where I work daily (WIP)\n> (2) \"MyRepo.git\" => --bare repository accessible to others. \"MyRepo\"\n> pushes ready changes to \"MyRepo.git\"\n> Dropping \".git\" extension causes confusion between these two quite\n> similarly named repositories.\n> \n> This problem can be easily solved by the patch below that removes the\n> code that strips off \".git\" extension.\n> \n> --Leo--\n> \n> ----8<-------------------\n> \n> builtin-fetch--tool.c | 2 --\n> builtin-fetch.c | 2 --\n> 2 files changed, 0 insertions(+), 4 deletions(-)\n> \n> diff --git a/builtin-fetch--tool.c b/builtin-fetch--tool.c\n> index 7460ab7..5d0b95f 100644\n> --- a/builtin-fetch--tool.c\n> +++ b/builtin-fetch--tool.c\n> @@ -160,8 +160,6 @@ static int append_fetch_head(FILE *fp,\n> \tfor (i = remote_len - 1; remote[i] == '/' && 0 <= i; i--)\n> \t\t;\n> \tremote_len = i + 1;\n> -\tif (4 < i && !strncmp(\".git\", remote + i - 3, 4))\n> -\t\tremote_len = i - 3;\n> \n> \tnote_len = 0;\n> \tif (*what) {\n> diff --git a/builtin-fetch.c b/builtin-fetch.c\n> index ee93d3a..28123a5 100644\n> --- a/builtin-fetch.c\n> +++ b/builtin-fetch.c\n> @@ -348,8 +348,6 @@ static int store_updated_refs(const char *url,\n> const char *remote_name,\n> \t\tfor (i = url_len - 1; url[i] == '/' && 0 <= i; i--)\n> \t\t\t;\n> \t\turl_len = i + 1;\n> -\t\tif (4 < i && !strncmp(\".git\", url + i - 3, 4))\n> -\t\t\turl_len = i - 3;\n> \n\nWill this still play nicely with\n\n git clone foo.git\n\n?\n\nOtherwise, please also fix the fallout from this patch.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"93495","messageId":"ee2a733e0810200808y657fe3d7y3158bfc00aa5e82a@mail.gmail.com","threadId":"15949","inReplyTo":"48FC5F1B.1050608@op5.se","subject":"Re: [PATCH] git-fetch should not strip off \".git\" extension","fromName":"Leo Razoumov","fromEmail":"slonik.az@gmail.com","sentAt":"2008-10-20T15:08:49Z","receivedAt":"2008-10-20T15:08:49Z","isPatch":true,"sender":{"key":"slonik.az@gmail.com","avatar":null},"body":"On 10/20/08, Andreas Ericsson wrote:\n> [..snip..]]\n> Will this still play nicely with\n>\n> git clone foo.git\n>\n> ?\n>\n> Otherwise, please also fix the fallout from this patch.\n>\n> --\n\nAndreas,\nthanks for the comment. I have been testing this patch for over two\nweeks already and so far encountered no problems. I routinely perform\n\"git clone foo.git\" and it works correctly creating new repo \"foo\" and\nproperly populating it.\n\n--Leo--\n"},{"id":"93528","messageId":"7vzlkz2jv7.fsf@gitster.siamese.dyndns.org","threadId":"15949","inReplyTo":"48FC5F1B.1050608@op5.se","subject":"Re: [PATCH] git-fetch should not strip off \".git\" extension","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-10-20T18:37:32Z","receivedAt":"2008-10-20T18:37:32Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andreas Ericsson writes:\n\n>>...\n>>\n>> builtin-fetch--tool.c | 2 --\n>> builtin-fetch.c | 2 --\n>> 2 files changed, 0 insertions(+), 4 deletions(-)\n>>\n>> diff --git a/builtin-fetch--tool.c b/builtin-fetch--tool.c\n>> index 7460ab7..5d0b95f 100644\n>> --- a/builtin-fetch--tool.c\n>> +++ b/builtin-fetch--tool.c\n>> @@ -160,8 +160,6 @@ static int append_fetch_head(FILE *fp,\n>> \tfor (i = remote_len - 1; remote[i] == '/' && 0 <= i; i--)\n>> \t\t;\n>> \tremote_len = i + 1;\n>> -\tif (4 < i && !strncmp(\".git\", remote + i - 3, 4))\n>> -\t\tremote_len = i - 3;\n>>\n>> \tnote_len = 0;\n>> \tif (*what) {\n>> diff --git a/builtin-fetch.c b/builtin-fetch.c\n>> index ee93d3a..28123a5 100644\n>> --- a/builtin-fetch.c\n>> +++ b/builtin-fetch.c\n>> @@ -348,8 +348,6 @@ static int store_updated_refs(const char *url,\n>> const char *remote_name,\n>> \t\tfor (i = url_len - 1; url[i] == '/' && 0 <= i; i--)\n>> \t\t\t;\n>> \t\turl_len = i + 1;\n>> -\t\tif (4 < i && !strncmp(\".git\", url + i - 3, 4))\n>> -\t\t\turl_len = i - 3;\n>>\n> \n> Will this still play nicely with\n>\n> git clone foo.git\n>\n> ?\n\nI think it would.\n\nAs far as I can tell, the only thing the patch changes is to disable the\nlong established \"repository name clean-up\" feature in the autogenerated\nmerge messages (iow, input to \"fmt-merge-msg\").\n"},{"id":"93589","messageId":"ee2a733e0810210323j249c3460x881af6d6aefc647c@mail.gmail.com","threadId":"15949","inReplyTo":"7vzlkz2jv7.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] git-fetch should not strip off \".git\" extension","fromName":"Leo Razoumov","fromEmail":"slonik.az@gmail.com","sentAt":"2008-10-21T10:23:57Z","receivedAt":"2008-10-21T10:23:57Z","isPatch":true,"sender":{"key":"slonik.az@gmail.com","avatar":null},"body":"On 10/20/08, Junio C Hamano wrote:\n> Andreas Ericsson writes:\n>\n> >>...\n>\n> >>\n> >> builtin-fetch--tool.c | 2 --\n> >> builtin-fetch.c | 2 --\n> >> 2 files changed, 0 insertions(+), 4 deletions(-)\n> >>\n> >> diff --git a/builtin-fetch--tool.c b/builtin-fetch--tool.c\n> >> index 7460ab7..5d0b95f 100644\n> >> --- a/builtin-fetch--tool.c\n> >> +++ b/builtin-fetch--tool.c\n> >> @@ -160,8 +160,6 @@ static int append_fetch_head(FILE *fp,\n> >> for (i = remote_len - 1; remote[i] == '/' && 0 <= i; i--)\n> >> ;\n> >> remote_len = i + 1;\n> >> - if (4 < i && !strncmp(\".git\", remote + i - 3, 4))\n> >> - remote_len = i - 3;\n> >>\n> >> note_len = 0;\n> >> if (*what) {\n> >> diff --git a/builtin-fetch.c b/builtin-fetch.c\n> >> index ee93d3a..28123a5 100644\n> >> --- a/builtin-fetch.c\n> >> +++ b/builtin-fetch.c\n> >> @@ -348,8 +348,6 @@ static int store_updated_refs(const char *url,\n> >> const char *remote_name,\n> >> for (i = url_len - 1; url[i] == '/' && 0 <= i; i--)\n> >> ;\n> >> url_len = i + 1;\n> >> - if (4 < i && !strncmp(\".git\", url + i - 3, 4))\n> >> - url_len = i - 3;\n> >>\n> >\n> > Will this still play nicely with\n> >\n> > git clone foo.git\n> >\n> > ?\n>\n>\n> I think it would.\n>\n> As far as I can tell, the only thing the patch changes is to disable the\n> long established \"repository name clean-up\" feature in the autogenerated\n> merge messages (iow, input to \"fmt-merge-msg\").\n\nEven though the old behavior is \"long established\", it introduces\nunnecessary ambiguity. If I have two repos\n\n(1) Foo #private repo where I do my daily work\n(2) Foo.git #exported public repo\n\nthe current behavior makes git messages confuse the repos.\n\n--Leo--\n"},{"id":"93615","messageId":"7vej29zy2r.fsf@gitster.siamese.dyndns.org","threadId":"15949","inReplyTo":"ee2a733e0810210323j249c3460x881af6d6aefc647c@mail.gmail.com","subject":"Re: [PATCH] git-fetch should not strip off \".git\" extension","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-10-21T16:56:28Z","receivedAt":"2008-10-21T16:56:28Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Leo Razoumov\" writes:\n\n> Even though the old behavior is \"long established\", it introduces\n> unnecessary ambiguity. If I have two repos\n> ...\n\nOf course. Now you know why people don't name such a pair of repositories\nlike that ;-).\n"},{"id":"93639","messageId":"81b0412b0810211506y400ba750k2613ba19f01fb57@mail.gmail.com","threadId":"15949","inReplyTo":"7vej29zy2r.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] git-fetch should not strip off \".git\" extension","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2008-10-21T22:06:55Z","receivedAt":"2008-10-21T22:06:55Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"2008/10/21 Junio C Hamano :\n> \"Leo Razoumov\" writes:\n>\n>> Even though the old behavior is \"long established\", it introduces\n>> unnecessary ambiguity. If I have two repos\n>> ...\n>\n> Of course. Now you know why people don't name such a pair of repositories\n> like that ;-).\n\nFWIW, I support Leo on that. The \"established\" behavior is stupid.\n"},{"id":"93640","messageId":"7vd4htwp6v.fsf@gitster.siamese.dyndns.org","threadId":"15949","inReplyTo":"81b0412b0810211506y400ba750k2613ba19f01fb57@mail.gmail.com","subject":"Re: [PATCH] git-fetch should not strip off \".git\" extension","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-10-21T22:36:40Z","receivedAt":"2008-10-21T22:36:40Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Alex Riesen\" writes:\n\n> 2008/10/21 Junio C Hamano :\n>> \"Leo Razoumov\" writes:\n>>\n>>> Even though the old behavior is \"long established\", it introduces\n>>> unnecessary ambiguity. If I have two repos\n>>> ...\n>>\n>> Of course. Now you know why people don't name such a pair of repositories\n>> like that ;-).\n>\n> FWIW, I support Leo on that. The \"established\" behavior is stupid.\n\nI am not inclined to respond to such an emotional argument. On the other\nhand, it is fair to say that the existing behaviour is established,\nbecause it is backed by a long history, which you can objectively verify.\n\nIf you think about it deeper, you will realize that it is not even clear\nif it is \"stupid\".\n\nMore importantly, the behaviour is consistent with the way how \"git fetch\"\nand \"git clone\" DWIMs the repository name by suffixing .git when the input\nlacks it. And this DWIMmery comes from the expectations that:\n\n (1) people name their repository project.git; and\n\n (2) people like using and seeing short names (iow, \"clone\n git://$somewhere/project\" is preferred over \"clone\n git://$somewhere/project.git\");\n\nIf a repository whose real location is git://$somewhere/project.git is\ncloned/fetched as git://$somewhere/project by people, recording the merge\nsource using the shorter name used by people to fetch from it is more\nconsistent. The patch breaks this consistency [*1*].\n\nWhat is clear is that you would confuse yourself if you have two\nrepositories A and A.git next to each other, and that is primarily because\nit breaks the above expectation.\n\ngit core-level rarely imposes such policies, but what Porcelains do is a\ndifferent matter.\n\nHence the suggestion: don't do it.\n\n[Footnote]\n\n*1* It would be a different matter if the patch at the same time removed\nthe fetch/clone DWIMmery. At least such a patch would be internally self\nconsistent.\n"},{"id":"93641","messageId":"81b0412b0810211543p6cb8c4ej49fb7fe70c3e2917@mail.gmail.com","threadId":"15949","inReplyTo":"7vd4htwp6v.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] git-fetch should not strip off \".git\" extension","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2008-10-21T22:43:09Z","receivedAt":"2008-10-21T22:43:09Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"2008/10/22 Junio C Hamano :\n> \"Alex Riesen\" writes:\n>>\n>> FWIW, I support Leo on that. The \"established\" behavior is stupid.\n>\n> I am not inclined to respond to such an emotional argument. On the other\n> hand, it is fair to say that the existing behaviour is established,\n> because it is backed by a long history, which you can objectively verify.\n\nI found it illogical (well, stupid) and inconvinient\n\n> *1* It would be a different matter if the patch at the same time removed\n> the fetch/clone DWIMmery. At least such a patch would be internally self\n> consistent.\n\nGood idea.\n"},{"id":"93642","messageId":"7v8wshwmgt.fsf@gitster.siamese.dyndns.org","threadId":"15949","inReplyTo":"7vd4htwp6v.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] git-fetch should not strip off \".git\" extension","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-10-21T23:35:30Z","receivedAt":"2008-10-21T23:35:30Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> More importantly, the behaviour is consistent with the way how \"git fetch\"\n> and \"git clone\" DWIMs the repository name by suffixing .git when the input\n> lacks it. And this DWIMmery comes from the expectations that:\n>\n> (1) people name their repository project.git; and\n>\n> (2) people like using and seeing short names (iow, \"clone\n> git://$somewhere/project\" is preferred over \"clone\n> git://$somewhere/project.git\");\n>\n> If a repository whose real location is git://$somewhere/project.git is\n> cloned/fetched as git://$somewhere/project by people, recording the merge\n> source using the shorter name used by people to fetch from it is more\n> consistent. The patch breaks this consistency [*1*].\n> ...\n> [Footnote]\n>\n> *1* It would be a different matter if the patch at the same time removed\n> the fetch/clone DWIMmery. At least such a patch would be internally self\n> consistent.\n\nActually, after looking at what the involved codepaths do, I am inclined\nto change my mind. Somehow I thought the transport.c infrastructure DWIMs\nand uses the result of DWIMmery throughout the program (iow, at the point\nin the codepath the patch touches, we cannot tell what the user originally\nasked for), which is not the case at all. That changes everything.\n\nThe current behaviour is Ok if you match your behaviour to the original\nexpectations, but:\n\n * if you clone from \"git://$somewhere/project\" originally, your\n remote.origin.url will not end with \".git\";\n\n * or equivalently, if your remote.origin.url does not end with \".git\".\n\nand when you fetch in such a repository with or without the patch, the\nresults are the same. URL without trailing \".git\".\n\nSo the change in the behaviour is only when you originally explicitly\nasked to clone \"git://$somewhere/project.git\". With the change, that wish\nis preserved. Without the change, \".git\" is unconditionally dropped.\n\nThe situation is the same if you explicitly ask to fetch from a URL that\nends with \".git\" (or \"/.git\"). With the change, the explicit \".git\" is\npreserved; without it, it is dropped.\n\nSo I now think the patch (if it were massaged into an applicable shape\nwith proper log message and sign-off) is an improvement.\n\nAlex, thanks for sanity checking ;-)\n"},{"id":"93655","messageId":"48FEDC63.8090104@op5.se","threadId":"15949","inReplyTo":"81b0412b0810211543p6cb8c4ej49fb7fe70c3e2917@mail.gmail.com","subject":"Re: [PATCH] git-fetch should not strip off \".git\" extension","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2008-10-22T07:55:15Z","receivedAt":"2008-10-22T07:55:15Z","isPatch":true,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Alex Riesen wrote:\n> 2008/10/22 Junio C Hamano :\n>> \"Alex Riesen\" writes:\n>>> FWIW, I support Leo on that. The \"established\" behavior is stupid.\n>> I am not inclined to respond to such an emotional argument. On the other\n>> hand, it is fair to say that the existing behaviour is established,\n>> because it is backed by a long history, which you can objectively verify.\n> \n> I found it illogical (well, stupid) and inconvinient\n> \n>> *1* It would be a different matter if the patch at the same time removed\n>> the fetch/clone DWIMmery. At least such a patch would be internally self\n>> consistent.\n> \n> Good idea.\n\nNo. Bad idea. That would not only break people's fetch configurations if\nthey've done clone on repos without passing .git, but also mean users\nwould have to remember if a particular server names their bare repos\n\"project.git\".\n\nIf you remove *all* DWIMmery from fetch/clone, you'd also break people's\nexpectations when they're fetching from each other, as they'd have to pass\n\"git://devpeer/project/.git\" instead of just \"git://devpeer/project\", which\nis what *looks* sane.\n\nA good idea would be to always report the name the user used. 'git clone'\nalready does that, recording the non-DWIMmed URL in the remotes config.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"93676","messageId":"ee2a733e0810220435v5f1bfa62y508f78f2d9bef8ba@mail.gmail.com","threadId":"15949","inReplyTo":"7vd4htwp6v.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] git-fetch should not strip off \".git\" extension","fromName":"Leo Razoumov","fromEmail":"slonik.az@gmail.com","sentAt":"2008-10-22T11:35:50Z","receivedAt":"2008-10-22T11:35:50Z","isPatch":true,"sender":{"key":"slonik.az@gmail.com","avatar":null},"body":"On 10/21/08, Junio C Hamano wrote:\n> \"Alex Riesen\" writes:\n>\n> > 2008/10/21 Junio C Hamano :\n> >> \"Leo Razoumov\" writes:\n> >>\n> >>> Even though the old behavior is \"long established\", it introduces\n> >>> unnecessary ambiguity. If I have two repos\n> >>> ...\n> >>\n> >> Of course. Now you know why people don't name such a pair of repositories\n> >> like that ;-).\n> >\n> > FWIW, I support Leo on that. The \"established\" behavior is stupid.\n>\n>\n> I am not inclined to respond to such an emotional argument. On the other\n> hand, it is fair to say that the existing behaviour is established,\n> because it is backed by a long history, which you can objectively verify.\n>\n> If you think about it deeper, you will realize that it is not even clear\n> if it is \"stupid\".\n>\n> More importantly, the behaviour is consistent with the way how \"git fetch\"\n> and \"git clone\" DWIMs the repository name by suffixing .git when the input\n> lacks it. And this DWIMmery comes from the expectations that:\n>\n> (1) people name their repository project.git; and\n>\n> (2) people like using and seeing short names (iow, \"clone\n> git://$somewhere/project\" is preferred over \"clone\n> git://$somewhere/project.git\");\n>\n> If a repository whose real location is git://$somewhere/project.git is\n> cloned/fetched as git://$somewhere/project by people, recording the merge\n> source using the shorter name used by people to fetch from it is more\n> consistent. The patch breaks this consistency [*1*].\n>\n> What is clear is that you would confuse yourself if you have two\n> repositories A and A.git next to each other, and that is primarily because\n> it breaks the above expectation.\n>\n> git core-level rarely imposes such policies, but what Porcelains do is a\n> different matter.\n>\n> Hence the suggestion: don't do it.\n>\n> [Footnote]\n>\n> *1* It would be a different matter if the patch at the same time removed\n> the fetch/clone DWIMmery. At least such a patch would be internally self\n> consistent.\n>\n\nI think this discussion went in the direction of \"correct\" versus\n\"convent\". I, personally, will choose correct over convenient any\ntime. Different people use git for different projects and their\nexpectations differ in this regard. In my case\nafter I do \"git clone Foo.git\" I get \"Foo\" repo side-by-side with\n\"Foo.git\" and the ambiguity becomes apparent.\n\nRegarding your footnote *1*. I agree with your suggestions and I can\nimprove the patch in the following way:\n\n(1) Fetch/clone messages/comments will refer to the source/destination\nrepos by their complete names without stripping off any parts\n(2) Searching for a source repo, clone/fetch will first try an exact\nmatch and if it fails it will remove/add \".git\" suffix and\n"},{"id":"93677","messageId":"ee2a733e0810220450i20dc81c5j488b513b5c0b781e@mail.gmail.com","threadId":"15949","inReplyTo":"7vd4htwp6v.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] git-fetch should not strip off \".git\" extension","fromName":"Leo Razoumov","fromEmail":"slonik.az@gmail.com","sentAt":"2008-10-22T11:50:24Z","receivedAt":"2008-10-22T11:50:24Z","isPatch":true,"sender":{"key":"slonik.az@gmail.com","avatar":null},"body":"My apologies!! I hit send button by mistake before message was\ncomplete. Please, see below a completed version.\n--Leo--\n\nOn 10/21/08, Junio C Hamano wrote:\n> \"Alex Riesen\" writes:\n>\n> > 2008/10/21 Junio C Hamano :\n> >> \"Leo Razoumov\" writes:\n> >>\n> >>> Even though the old behavior is \"long established\", it introduces\n> >>> unnecessary ambiguity. If I have two repos\n> >>> ...\n> >>\n> >> Of course. Now you know why people don't name such a pair of repositories\n> >> like that ;-).\n> >\n> > FWIW, I support Leo on that. The \"established\" behavior is stupid.\n>\n>\n> I am not inclined to respond to such an emotional argument. On the other\n> hand, it is fair to say that the existing behaviour is established,\n> because it is backed by a long history, which you can objectively verify.\n>\n> If you think about it deeper, you will realize that it is not even clear\n> if it is \"stupid\".\n>\n> More importantly, the behaviour is consistent with the way how \"git fetch\"\n> and \"git clone\" DWIMs the repository name by suffixing .git when the input\n> lacks it. And this DWIMmery comes from the expectations that:\n>\n> (1) people name their repository project.git; and\n>\n> (2) people like using and seeing short names (iow, \"clone\n> git://$somewhere/project\" is preferred over \"clone\n> git://$somewhere/project.git\");\n>\n> If a repository whose real location is git://$somewhere/project.git is\n> cloned/fetched as git://$somewhere/project by people, recording the merge\n> source using the shorter name used by people to fetch from it is more\n> consistent. The patch breaks this consistency [*1*].\n>\n> What is clear is that you would confuse yourself if you have two\n> repositories A and A.git next to each other, and that is primarily because\n> it breaks the above expectation.\n>\n> git core-level rarely imposes such policies, but what Porcelains do is a\n> different matter.\n>\n> Hence the suggestion: don't do it.\n>\n> [Footnote]\n>\n> *1* It would be a different matter if the patch at the same time removed\n> the fetch/clone DWIMmery. At least such a patch would be internally self\n> consistent.\n>\n\nI think this discussion went in the direction of \"correct\" versus\n\"convent\". I, personally, will choose correct over convenient any\ntime. Different people use git for different projects and their\nexpectations differ in this regard. In my case\nafter I do \"git clone Foo.git\" I get \"Foo\" repo side-by-side with\n\"Foo.git\" and the ambiguity becomes apparent.\n\nRegarding your footnote *1*. I agree with your suggestions and I can\nimprove the patch in the following way:\n\n(P1) Fetch/clone messages/records will refer to the source/destination\nrepos by their complete names without stripping off any parts of the name.\n\n(P2) Searching for a source repo, clone/fetch will first try an exact\nmatch and if it fails it will remove/add \".git\" suffix as needed and retry.\n\nItem (P2) will provide the convenience, while item (P1) still\nguarantees correctness.\n\nPlease, let me know if such approach is more satisfactory.\n\n--Leo--\n"}]}