{"thread":{"id":"56192","subject":"[PATCH] clone: Remove constraint on --bare and --origin","startedAt":"2021-08-01T08:25:57Z","lastAt":"2021-08-08T02:03:41Z","messageCount":13,"participants":["Øystein Walle","Junio C Hamano","Ævar Arnfjörð Bjarmason","Roman Neuhauser"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"431648","messageId":"20210801082546.18543-1-oystwa@gmail.com","threadId":"56192","inReplyTo":null,"subject":"[PATCH] clone: Remove constraint on --bare and --origin","fromName":"Øystein Walle","fromEmail":"oystwa@gmail.com","sentAt":"2021-08-01T08:25:46Z","receivedAt":"2021-08-01T08:25:57Z","isPatch":true,"sender":{"key":"oystwa@gmail.com","avatar":"https://avatars.githubusercontent.com/u/794585?v=4"},"body":"This test has been present since long before clone was ported to C. Now\nthere is no need for it, and since df61c88979 (clone: also configure url\nfor bare clones, 2010-03-29) it's especially useful to allow both\noptions.\n\nSigned-off-by: Øystein Walle <oystwa@gmail.com>\n---\n\nA question on this constraint popped up on #git the other day. I\ninvestigated a bit and found no particular reason for its existence. All\ntests still pass (except the one removed here) and the behavior is as\nexpected. I realize it might have gone under the radar for 11 years but\nit's still worth the noise to remove it, in my opinion.\n\nI wanted to include a bit on the reasoning for the original check in the\ncommit message but I couldn't find it. \n\n builtin/clone.c          | 3 ---\n t/t5606-clone-options.sh | 8 --------\n 2 files changed, 11 deletions(-)\n\ndiff --git a/builtin/clone.c b/builtin/clone.c\nindex 66fe66679c..70ec72ea85 100644\n--- a/builtin/clone.c\n+++ b/builtin/clone.c\n@@ -1014,9 +1014,6 @@ int cmd_clone(int argc, const char **argv, const char *prefix)\n \t\toption_bare = 1;\n \n \tif (option_bare) {\n-\t\tif (option_origin)\n-\t\t\tdie(_(\"--bare and --origin %s options are incompatible.\"),\n-\t\t\t    option_origin);\n \t\tif (real_git_dir)\n \t\t\tdie(_(\"--bare and --separate-git-dir are incompatible.\"));\n \t\toption_no_checkout = 1;\ndiff --git a/t/t5606-clone-options.sh b/t/t5606-clone-options.sh\nindex 3a595c0f82..4a8a2ca6f7 100755\n--- a/t/t5606-clone-options.sh\n+++ b/t/t5606-clone-options.sh\n@@ -30,14 +30,6 @@ test_expect_success 'rejects invalid -o/--origin' '\n \n '\n \n-test_expect_success 'disallows --bare with --origin' '\n-\n-\ttest_must_fail git clone -o foo --bare parent clone-bare-o 2>err &&\n-\ttest_debug \"cat err\" &&\n-\ttest_i18ngrep -e \"--bare and --origin foo options are incompatible\" err\n-\n-'\n-\n test_expect_success 'disallows --bare with --separate-git-dir' '\n \n \ttest_must_fail git clone --bare --separate-git-dir dot-git-destiation parent clone-bare-sgd 2>err &&\n-- \n2.27.0\n\n"},{"id":"431658","messageId":"xmqq4kc8zj02.fsf@gitster.g","threadId":"56192","inReplyTo":"20210801082546.18543-1-oystwa@gmail.com","subject":"Re: [PATCH] clone: Remove constraint on --bare and --origin","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-08-02T02:18:53Z","receivedAt":"2021-08-02T02:19:06Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Øystein Walle <oystwa@gmail.com> writes:\n\n> This test has been present since long before clone was ported to C. Now\n> there is no need for it, and since df61c88979 (clone: also configure url\n> for bare clones, 2010-03-29) it's especially useful to allow both\n> options.\n>\n> Signed-off-by: Øystein Walle <oystwa@gmail.com>\n> ---\n>\n> A question on this constraint popped up on #git the other day. I\n> investigated a bit and found no particular reason for its existence. All\n> tests still pass (except the one removed here) and the behavior is as\n> expected. I realize it might have gone under the radar for 11 years but\n> it's still worth the noise to remove it, in my opinion.\n>\n> I wanted to include a bit on the reasoning for the original check in the\n> commit message but I couldn't find it. \n\nI suspect that this originally was because \"git clone --bare\" does\nnot use any remote-tracking branch (i.e. no refs/remotes/origin/*)\nand the only expected way to update a \"git clone --bare\" repository\nwas to run \"git fetch --mirror [--prune]\", so there was no need to\nmake the nickname \"origin\" to be configurable.\n\nI do not offhand know what other features in \"git clone --bare\" that\nwere added since then affect the resulting repository so that the\nname \"origin\" it leaves there (perhaps in its configuration, if not\nnames in ref hierarchy) is visible to the end user and deserves to\nbe customizable.\n\nIn short, I think the \"don't use --origin in a bare repository\" was\nnot because \"doing so will break X and Y\", but because \"doing so\ndoes not make any practical difference\".  So I am OK to lift this\ncheck.  It is a small enough change that is easy to revert if there\nwere some valid reasons we failed to consider.\n\nThanks.\n"},{"id":"431665","messageId":"8735rsqlal.fsf@evledraar.gmail.com","threadId":"56192","inReplyTo":"20210801082546.18543-1-oystwa@gmail.com","subject":"Re: [PATCH] clone: Remove constraint on --bare and --origin","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-08-02T08:53:04Z","receivedAt":"2021-08-02T08:54:17Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Sun, Aug 01 2021, Øystein Walle wrote:\n\n> This test has been present since long before clone was ported to C. Now\n> there is no need for it, and since df61c88979 (clone: also configure url\n> for bare clones, 2010-03-29) it's especially useful to allow both\n> options.\n>\n> Signed-off-by: Øystein Walle <oystwa@gmail.com>\n> ---\n>\n> A question on this constraint popped up on #git the other day. I\n> investigated a bit and found no particular reason for its existence. All\n> tests still pass (except the one removed here) and the behavior is as\n> expected. I realize it might have gone under the radar for 11 years but\n> it's still worth the noise to remove it, in my opinion.\n>\n> I wanted to include a bit on the reasoning for the original check in the\n> commit message but I couldn't find it. \n\nAside from working in Junio's reply as a summary of the original\njustification in the commit message for a v2...\n\n> -test_expect_success 'disallows --bare with --origin' '\n> -\n> -\ttest_must_fail git clone -o foo --bare parent clone-bare-o 2>err &&\n> -\ttest_debug \"cat err\" &&\n> -\ttest_i18ngrep -e \"--bare and --origin foo options are incompatible\" err\n> -\n> -'\n> -\n\nThis just removes the only test, if it's \"especially useful\" to allow\nboth options let's replace this with a test that shows and tests for\nthose use-cases.\n"},{"id":"431737","messageId":"20210802174944.53745-1-oystwa@gmail.com","threadId":"56192","inReplyTo":"8735rsqlal.fsf@evledraar.gmail.com","subject":"[PATCH v2] clone: Allow combining --bare and --origin","fromName":"Øystein Walle","fromEmail":"oystwa@gmail.com","sentAt":"2021-08-02T17:49:44Z","receivedAt":"2021-08-02T17:49:59Z","isPatch":true,"sender":{"key":"oystwa@gmail.com","avatar":"https://avatars.githubusercontent.com/u/794585?v=4"},"body":"The constraint on passing both these options simultaneously has been\npresent since long before clone was ported to C. At the time no\nconfiguration referencing the remote repository was written at all in\nbare clones.\n\nSince df61c88979 (clone: also configure url for bare clones, 2010-03-29)\nthe remote repository is mentioned in the configuration file also for\nbare repos, so it makes sense to allow the user to rename it if they\nwish.\n\nSigned-off-by: Øystein Walle <oystwa@gmail.com>\n---\n\nHi Junio and Ævar,\n\nI investigated a bit more and updated the commit message accordingly.\nInstead of just removing the test I have replaced it with one that\nchecks that the behavior is as intended. \n\nÆvar, I was a bit melodramatic when I wrote \"especially useful\". I have\ntoned the commit message down a bit :-) In truth, I don't personally\nhave a use-case for this (I did reach out to the person who asked about\nit in #git but did't get a reply) and have no problems with seeing this\npatch ultimately rejected. It's just a result of me seeing it asked\nabout and getting an itch from it. But in my humble opinion this is now\nan \"artificial\" constraint (for lack of a better term) and should be\nremoved on the grounds that there is no reason for it to be there in the\nfirst place.\n\nThanks,\nØsse\n\n builtin/clone.c          |  3 ---\n t/t5606-clone-options.sh | 10 +++++-----\n 2 files changed, 5 insertions(+), 8 deletions(-)\n\ndiff --git a/builtin/clone.c b/builtin/clone.c\nindex 66fe66679c..70ec72ea85 100644\n--- a/builtin/clone.c\n+++ b/builtin/clone.c\n@@ -1014,9 +1014,6 @@ int cmd_clone(int argc, const char **argv, const char *prefix)\n \t\toption_bare = 1;\n \n \tif (option_bare) {\n-\t\tif (option_origin)\n-\t\t\tdie(_(\"--bare and --origin %s options are incompatible.\"),\n-\t\t\t    option_origin);\n \t\tif (real_git_dir)\n \t\t\tdie(_(\"--bare and --separate-git-dir are incompatible.\"));\n \t\toption_no_checkout = 1;\ndiff --git a/t/t5606-clone-options.sh b/t/t5606-clone-options.sh\nindex 3a595c0f82..c40dde816d 100755\n--- a/t/t5606-clone-options.sh\n+++ b/t/t5606-clone-options.sh\n@@ -30,12 +30,12 @@ test_expect_success 'rejects invalid -o/--origin' '\n \n '\n \n-test_expect_success 'disallows --bare with --origin' '\n-\n-\ttest_must_fail git clone -o foo --bare parent clone-bare-o 2>err &&\n-\ttest_debug \"cat err\" &&\n-\ttest_i18ngrep -e \"--bare and --origin foo options are incompatible\" err\n+test_expect_success '--bare works with -o/--origin' '\n \n+\tgit clone --bare --origin=somewhere parent clone-bare &&\n+\turl=\"$(git -C clone-bare config --local remote.somewhere.url)\" &&\n+\ttest -n \"$url\" &&\n+\ttest_must_fail git -C clone-bare config --local remote.origin.url\n '\n \n test_expect_success 'disallows --bare with --separate-git-dir' '\n-- \n2.27.0\n\n"},{"id":"431884","messageId":"xmqqv94mtdyj.fsf@gitster.g","threadId":"56192","inReplyTo":"20210802174944.53745-1-oystwa@gmail.com","subject":"Re: [PATCH v2] clone: Allow combining --bare and --origin","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-08-03T21:28:52Z","receivedAt":"2021-08-03T21:29:04Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Øystein Walle <oystwa@gmail.com> writes:\n\n> The constraint on passing both these options simultaneously has been\n> present since long before clone was ported to C. At the time no\n> configuration referencing the remote repository was written at all in\n> bare clones.\n>\n> Since df61c88979 (clone: also configure url for bare clones, 2010-03-29)\n> the remote repository is mentioned in the configuration file also for\n> bare repos, so it makes sense to allow the user to rename it if they\n> wish.\n\nSounds sensible.\n\n> Ævar, I was a bit melodramatic when I wrote \"especially useful\". I have\n> toned the commit message down a bit :-) In truth, I don't personally\n> have a use-case for this (I did reach out to the person who asked about\n> it in #git but did't get a reply) and have no problems with seeing this\n> patch ultimately rejected. It's just a result of me seeing it asked\n> about and getting an itch from it. But in my humble opinion this is now\n> an \"artificial\" constraint (for lack of a better term) and should be\n> removed on the grounds that there is no reason for it to be there in the\n> first place.\n\nYup, that is exactly my thought when I responded to your v1.\n\n> +test_expect_success '--bare works with -o/--origin' '\n> +\tgit clone --bare --origin=somewhere parent clone-bare &&\n> +\turl=\"$(git -C clone-bare config --local remote.somewhere.url)\" &&\n> +\ttest -n \"$url\" &&\n> +\ttest_must_fail git -C clone-bare config --local remote.origin.url\n>  '\n\nIt is somewhat unfortunate that we do not say what the name of the\n\"origin\" is anywhere in the resulting configuration file.  The only\nway to tell that \"--origin somewhere\" was used is to notice that\nthere is only one remote and its name is \"somewhere\".  Instead of\n\"usually the thing is called 'origin', so let's make sure it does\nnot exist\", we may want to say \"there is only one remote and it is\ncalled somewhere because that is how we named it\", i.e.\n\n\tgit -C clone-bare config --name-only \\\n\t\t--get-regexp \"remote\\..*\\.url\" >actual &&\n\techo remote.somewhere.url >expect &&\n\ttest_cmp actual expect\n\nBut stepping back a bit, I think this shows another reason why use\nof '--origin' with '--bare' as-is may not be so pleasant to use.\n\nIn a repository _with_ working tree, this lack of \"what is 'origin'\ncalled in this repository?\" is not a problem because you'd get these\nafter cloning:\n\n    [remote \"somewhere\"]\n\turl = ...\n\tfetch = ...\n    [branch \"master\"]\n\tremote = \"somewhere\"\n\tmerge = refs/heads/master\n\nYou can say \"git fetch\" or \"git pull\" without the remote name and we\nwill know which remote to interact with, because our branch knows\nwhich remote to fetch from.\n\nIn a bare repository, however, you only get this:\n\n    [remote \"somewhere\"]\n\turl = ...\n\nI do not think \"git fetch\" in such a repository knows that it needs\nto fetch from 'somewhere', even whe it is the only remote repository\navailable to us.\n\nWe may need a bit _more_ work (e.g. leave an optional configuration\nremote.originName = \"somewhere\" when \"--bare --origin somewhere\" is\nused, and teach \"git fetch\" to pay attention to it, instead of\nassuming 'origin') before \"--bare --origin somewhere\" becomes truly\nusable.  And I suspect that \"git fetch\" is not the only one that\nneeds such \"fix\".\n"},{"id":"431920","messageId":"xmqqzgtyqa9q.fsf@gitster.g","threadId":"56192","inReplyTo":"20210802174944.53745-1-oystwa@gmail.com","subject":"Re: [PATCH v2] clone: Allow combining --bare and --origin","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-08-04T01:16:49Z","receivedAt":"2021-08-04T01:16:53Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Øystein Walle <oystwa@gmail.com> writes:\n\n> diff --git a/t/t5606-clone-options.sh b/t/t5606-clone-options.sh\n> index 3a595c0f82..c40dde816d 100755\n> --- a/t/t5606-clone-options.sh\n> +++ b/t/t5606-clone-options.sh\n> @@ -30,12 +30,12 @@ test_expect_success 'rejects invalid -o/--origin' '\n>  \n>  '\n>  \n> -test_expect_success 'disallows --bare with --origin' '\n> -\n> -\ttest_must_fail git clone -o foo --bare parent clone-bare-o 2>err &&\n> -\ttest_debug \"cat err\" &&\n> -\ttest_i18ngrep -e \"--bare and --origin foo options are incompatible\" err\n> +test_expect_success '--bare works with -o/--origin' '\n>  \n> +\tgit clone --bare --origin=somewhere parent clone-bare &&\n> +\turl=\"$(git -C clone-bare config --local remote.somewhere.url)\" &&\n> +\ttest -n \"$url\" &&\n> +\ttest_must_fail git -C clone-bare config --local remote.origin.url\n>  '\n\nThis breaks a later step that creates clone-bare as this used to use\nclone-bare-o and the name was available.\n\nUsing clone-bare-o as it used to would probably be the easiest fix.\n\n>  \n>  test_expect_success 'disallows --bare with --separate-git-dir' '\n"},{"id":"431953","messageId":"20210804133010.25855-1-oystwa@gmail.com","threadId":"56192","inReplyTo":"xmqqv94mtdyj.fsf@gitster.g","subject":"Re: [PATCH v2] clone: Allow combining --bare and --origin","fromName":"Øystein Walle","fromEmail":"oystwa@gmail.com","sentAt":"2021-08-04T13:30:10Z","receivedAt":"2021-08-04T13:30:21Z","isPatch":true,"sender":{"key":"oystwa@gmail.com","avatar":"https://avatars.githubusercontent.com/u/794585?v=4"},"body":"Hi again,\n\nThanks for accepting the patch.\n\n> It is somewhat unfortunate that we do not say what the name of the\n> \"origin\" is anywhere in the resulting configuration file.  The only\n> way to tell that \"--origin somewhere\" was used is to notice that there\n> is only one remote and its name is \"somewhere\".\n\nThis reads as self-contradictory to me. The word \"origin\" is nowhere in\nthe configuration file, that's true. But that's because the user chose\nit to be that way, and the name the user chose is in the there.\n\nThe reason I see it as self-contradictory is that I see two different\nusages of the word \"origin\" in your email:\n\n 1. A *term* meaning the repository that was cloned (e.g. 'name of the\n \"origin\"', remote.originName)\n\n 2. The *name* of a remote ('there is only one remote and its name is\n [not \"origin\"]')\n\nSeems you are aware since you write it in quotes :-) \n\nBoth usages appear in the wild and are even mixed sometimes, but in my\nexperience it's not a big deal; it's usually obvious from context. I\nthink the second usage is the common one, but the name is so common that\nit leads to the first. Is this something we'd like to tackle? If so, it\njust occured to me that it certainly doesn't help that the switch to\nchange the name referring to the repo that was cloned from \"origin\" to\nsomething else is \"--origin\".\n\n> I do not think \"git fetch\" in such a repository knows that it needs to\n> fetch from 'somewhere', even whe it is the only remote repository\n> available to us.\n\nChanging git fetch to fall back to a remote not named \"origin\" if that\nis the only one configured makes perfect sense to me. (I am skeptical\nabout remotes.originName since that favors the first usage outlined\nabove.)\n\nI have cc'ed the origin (pun overtly intended) of this patch and\ndiscussion for their take on it.\n\n> Instead of \"usually the thing is called 'origin', so let's make sure\n> it does not exist\", we may want to say \"there is only one remote and\n> it is called somewhere because that is how we named it\", i.e.\n>\n>\tgit -C clone-bare config --name-only \\ --get-regexp\n>\t\"remote\\..*\\.url\" >actual && echo remote.somewhere.url >expect\n>\t&& test_cmp actual expect\n\nThis seems like like a better test than the one I wrote.\n\nBy the way, I noticed you already fixed my mistake with the repo name.\nThanks for that. I sent this as a v2, but as you can imagine I did it in\ntwo steps in real life. First I removed the test then later I wrote a\nnew one, and in between I rebased my changes. In the mean time new tests\nwere added. I noticed they failed, but I didn't realize that was my\nfault.\n\nØsse\n"},{"id":"431963","messageId":"xmqqbl6dqgvc.fsf@gitster.g","threadId":"56192","inReplyTo":"20210804133010.25855-1-oystwa@gmail.com","subject":"Re: [PATCH v2] clone: Allow combining --bare and --origin","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-08-04T17:06:31Z","receivedAt":"2021-08-04T17:06:37Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Øystein Walle <oystwa@gmail.com> writes:\n\n> Hi again,\n>\n> Thanks for accepting the patch.\n>\n>> It is somewhat unfortunate that we do not say what the name of the\n>> \"origin\" is anywhere in the resulting configuration file.  The only\n>> way to tell that \"--origin somewhere\" was used is to notice that there\n>> is only one remote and its name is \"somewhere\".\n>\n> This reads as self-contradictory to me. The word \"origin\" is nowhere in\n> the configuration file, that's true. But that's because the user chose\n> it to be that way, and the name the user chose is in the there.\n\nIn other words, if there were two remotes in the configuration file,\nyou cannot tell which one was given to --origin when you made the\nrepository with \"git clone\".\n\n> The reason I see it as self-contradictory is that I see two different\n> usages of the word \"origin\" in your email:\n>\n>  1. A *term* meaning the repository that was cloned (e.g. 'name of the\n>  \"origin\"', remote.originName)\n>\n>  2. The *name* of a remote ('there is only one remote and its name is\n>  [not \"origin\"]')\n>\n> Seems you are aware since you write it in quotes :-) \n\nMay be but #1 is not all that interesting.  \n\nI meant the only one thing.  The user told Git that 'somewhere' is\nthe word, not 'origin' that is used by those who use the default\nconfiguration, will be used to refer to the remote the repository\nwas cloned from.  In the first paragraph you quoted, I was referring\nto the fact that the knowledge will be lost once you did \"git remote\nadd elsewhere\".\n\nWe cannot tell between 'somewhere' and 'elsewhere', which one is\nwhat those who use the default configuration would refer to\n'origin'---presumably, 'somewhere' being the --origin's argument\nwhen \"git clone\" was run, has some significance over 'elsewhere' in\nthe user's mind, even after the latter is added to the repository.\n\nBut we'd end up treating them the same.  And something like\nremote.originName would help that.  Otherwise, we'd end up sending\nthis message:\n\n    Even if we give \"--bare --origin yourfavouritename\" to you now,\n    unlike how 'origin' is treated in the default case, in the\n    resulting repository, 'yourfavouritename' is not special at all.\n\nSome people may want to treat yourfavouritename is not special at\nall, while some people may want to treat yourfavouritename truly as\na replacement for 'origin' that is the default.  The message we\nwould be sending is that we'd ignore the latter folks.\n\n"},{"id":"432205","messageId":"YQ2aXpfzyOOUFhQk@isis.sigpipe.cz","threadId":"56192","inReplyTo":"xmqqbl6dqgvc.fsf@gitster.g","subject":"Re: [PATCH v2] clone: Allow combining --bare and --origin","fromName":"Roman Neuhauser","fromEmail":"rn+git@sigpipe.cz","sentAt":"2021-08-06T20:23:58Z","receivedAt":"2021-08-06T20:32:45Z","isPatch":true,"sender":{"key":"rn+git@sigpipe.cz","avatar":null},"body":"Hello,\n\ni'm \"the user\" in this story.  Muchas gracias to osse for turning\nmy bickering into a patch.\n\nA little background.  I use --origin a lot (or git remmote rename\nafterwards), because origin carries no information about the remote\nrepository, and I could have cloned any of those.  The URL I used\nin `git clone` has little to do with which remotes I'll want to\npull from and which I'll want to push to.  \"origin\" is suspicious\nand I'm used to giving my remotes names that mean something to me.\n\nMy need for git clone --bare --origin surfaced when I was writing\na tool for versioning dotfiles (don't we all have one).  It has to\nbe able to work with pre-existing files in the home dir:\n\n$ git dirs clone $url x\n# git-dir is $PWD/.git-dirs/repo.d/x\n# work-tree is $PWD\n\nI used git clone --bare / git config core.bare false /\ngit config core.worktree ... and hit the error message when I tried\nto add support for --origin.\n\n# gitster@pobox.com / 2021-08-04 10:06:31 -0700:\n> In other words, if there were two remotes in the configuration file,\n> you cannot tell which one was given to --origin when you made the\n> repository with \"git clone\".\n\nI'm not sure why this matters (not saying it doesn't).\n \n> But we'd end up treating them the same.  And something like\n> remote.originName would help that.  Otherwise, we'd end up sending\n> this message:\n> \n>     Even if we give \"--bare --origin yourfavouritename\" to you now,\n>     unlike how 'origin' is treated in the default case, in the\n>     resulting repository, 'yourfavouritename' is not special at all.\n\nIsn't that the case in non-bare repositories as well?\nBTW I don't like special cases but realize that the \"origin\" ship has\nsailed long ago.\n \n> Some people may want to treat yourfavouritename is not special at\n> all, while some people may want to treat yourfavouritename truly as\n> a replacement for 'origin' that is the default.  The message we\n> would be sending is that we'd ignore the latter folks.\n \nCan't they just continue doing what they've been doing so far,\nthat is leave it at \"origin\"?  I'm not sure this would be my concern\nas a user of this feature.\n\n-- \nroman\n"},{"id":"432214","messageId":"xmqqh7g2gr1s.fsf@gitster.g","threadId":"56192","inReplyTo":"YQ2aXpfzyOOUFhQk@isis.sigpipe.cz","subject":"Re: [PATCH v2] clone: Allow combining --bare and --origin","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-08-06T22:13:35Z","receivedAt":"2021-08-06T22:13:39Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Roman Neuhauser <rn+git@sigpipe.cz> writes:\n\n>> But we'd end up treating them the same.  And something like\n>> remote.originName would help that.  Otherwise, we'd end up sending\n>> this message:\n>> \n>>     Even if we give \"--bare --origin yourfavouritename\" to you now,\n>>     unlike how 'origin' is treated in the default case, in the\n>>     resulting repository, 'yourfavouritename' is not special at all.\n>\n> Isn't that the case in non-bare repositories as well?\n\nYou have branches that are checked out.  The first branch that you'd\npresumably be using as the primary (traditionally called 'master')\nknows that the nickname used to call the remote it integrates with\nas the value of branch.master.remote\n\nIn a bare repository, there is no such clue.\n\n> Can't they just continue doing what they've been doing so far,\n> that is leave it at \"origin\"?  I'm not sure this would be my concern\n> as a user of this feature.\n\nThat answer can be thrown back at you.  You can leave it at \"origin\"\nwhen using \"--bare\" ;-).\n\nThe posted patch is a good first step to allow both options to be\nused at the same time.  Without the first step, these two options\ncannot coexist.\n\nBut I am also saying that the first step alone is an inadequate\nsolution that goes only halfway.  If you can get yourfavouritename,\nwhile others cannot use their favourite names, that is not a\nsatisfying solution.\n"},{"id":"432243","messageId":"YQ5r/uE2A8w9BAZz@isis.sigpipe.cz","threadId":"56192","inReplyTo":"xmqqh7g2gr1s.fsf@gitster.g","subject":"Re: [PATCH v2] clone: Allow combining --bare and --origin","fromName":"Roman Neuhauser","fromEmail":"rn+git@sigpipe.cz","sentAt":"2021-08-07T11:18:22Z","receivedAt":"2021-08-07T11:19:31Z","isPatch":true,"sender":{"key":"rn+git@sigpipe.cz","avatar":null},"body":"# gitster@pobox.com / 2021-08-06 15:13:35 -0700:\n> Roman Neuhauser <rn+git@sigpipe.cz> writes:\n> \n> >> But we'd end up treating them the same.  And something like\n> >> remote.originName would help that.  Otherwise, we'd end up sending\n> >> this message:\n> >> \n> >>     Even if we give \"--bare --origin yourfavouritename\" to you now,\n> >>     unlike how 'origin' is treated in the default case, in the\n> >>     resulting repository, 'yourfavouritename' is not special at all.\n> >\n> > Isn't that the case in non-bare repositories as well?\n> \n> You have branches that are checked out.  The first branch that you'd\n> presumably be using as the primary (traditionally called 'master')\n> knows that the nickname used to call the remote it integrates with\n> as the value of branch.master.remote\n\naha, i see that as a special (heh) case, an exception. :)\ni spend most of my time on branches with no upstram.  sure, they're\nextensions of master and such, but they have no upstream themselves.\nand since there's no \"origin\" remote in my repos:\n\n  git checkout -b fix-this-or-that master\n  # tadaa, git fetch does nothing[1]\n\ngit fetch losing the hardcoded \"origin\" in favor of a configurable\nvalue would be an improvement, yes.\n\n> > Can't they just continue doing what they've been doing so far,\n> > that is leave it at \"origin\"?  I'm not sure this would be my concern\n> > as a user of this feature.\n\nhm, that last sentence came out wrong.  i meant to say that as a user\nof this feature, i would not mind having to provide and explicit remote.\n\n> That answer can be thrown back at you.  You can leave it at \"origin\"\n> when using \"--bare\" ;-).\n\nhow would that help the people who yearn for clone --bare --origin\nbut wouldn't use it if it meant fetch with explicit remotes?\n\n> The posted patch is a good first step to allow both options to be\n> used at the same time.  Without the first step, these two options\n> cannot coexist.\n\ni agree.\n \n> But I am also saying that the first step alone is an inadequate\n> solution that goes only halfway.  If you can get yourfavouritename,\n> while others cannot use their favourite names, that is not a\n> satisfying solution.\n\ni don't see how the patch in its current form prevents anyone from\nnaming --origin whatever they want (within the accepted syntax).\n\n---\n\ni think a step back is in order.  git fetch --all would work,\ngit remote update would work.  if the issue is the imaginary\nguy's ability to update the bare repo without peeking inside\nconfig, either of these commands has him covered.\n\nif the goal is to enable git fetch w/o --all or any other remote\nspecification then i'd say remote.fetchDefault would be a nice\nmirror to remote.pushDefault.  this glaring asymmetry would go away:\n\n  If no remote is configured, or if you are not on any branch,\n  it defaults to origin for fetching and remote.pushDefault\n  for pushing.\n\nif you want the repo to remember where it was cloned from,\nthen again, remote.fetchDefault can fill that role.  obviously\nmutable, but any setting would be, and i just don't see a problem\nwith that.\n\ncoming back to a question that fell below the radar:\n\n# gitster@pobox.com / 2021-08-04 10:06:31 -0700:\n> In other words, if there were two remotes in the configuration file,\n> you cannot tell which one was given to --origin when you made the\n> repository with \"git clone\".\n\nwhen does this matter?\n\n---\n\nlooking over the earlier emails, i'd like to reiterate one thing:\n\n> We cannot tell between 'somewhere' and 'elsewhere', which one is\n> what those who use the default configuration would refer to\n> 'origin'---presumably, 'somewhere' being the --origin's argument\n> when \"git clone\" was run, has some significance over 'elsewhere' in\n> the user's mind, even after the latter is added to the repository.\n\ni can't speak for others, but with me, this assumption is flat out\nwrong.  half my \"working copies\" get cloned from upstream sources\nand i add a remote to publish my changes from later, while the other\nhalf happens the other way around.  the urls given to git clone\ndon't mean... much[2].\n\nfinally, this notion that --origin in a regular clone works just like\n\"origin\" is generally false.  relevant to bare repos, if you don't\nhave any branch checked out, it goes to \"origin\".  iow if symmetry\nbetween regular and bare clones is the goal, then mission accomplished,\nthey already behave the same.\n\n\n[1] not only does it do nothing, it does it without a beep, which,\n    aside from the runtime, looks just like a successful fetch from\n    a remote i'm up-to-date with.\n\n[2] https://www.youtube.com/watch?v=WO2q1iQX2UA\n\n-- \nroman; btw, git-pull is backwards\n"},{"id":"432260","messageId":"xmqq4kc0j4cd.fsf_-_@gitster.g","threadId":"56192","inReplyTo":"xmqqbl6dqgvc.fsf@gitster.g","subject":"Re* [PATCH v2] clone: Allow combining --bare and --origin","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-08-07T22:08:02Z","receivedAt":"2021-08-07T22:08:07Z","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>>> It is somewhat unfortunate that we do not say what the name of the\n>>> \"origin\" is anywhere in the resulting configuration file.  The only\n>>> way to tell that \"--origin somewhere\" was used is to notice that there\n>>> is only one remote and its name is \"somewhere\".\n>> ...\n> But we'd end up treating them the same.  And something like\n> remote.originName would help that.  Otherwise, we'd end up sending\n> this message:\n>\n>     Even if we give \"--bare --origin yourfavouritename\" to you now,\n>     unlike how 'origin' is treated in the default case, in the\n>     resulting repository, 'yourfavouritename' is not special at all.\n>\n> Some people may want to treat yourfavouritename is not special at\n> all, while some people may want to treat yourfavouritename truly as\n> a replacement for 'origin' that is the default.  The message we\n> would be sending is that we'd ignore the latter folks.\n\nSo, let's illustrate one of the things that is needed after the good\nfirst step to allow --bare --origin=yourfavouritename used together.\n\nThere may be other things that needs fixing, of course, but we need\nto start from somewhere.\n\n---- >8 -------- >8 -------- >8 -------- >8 -------- >8 -------- >8 ----\nSubject: [PATCH] remote: fall back on the sole remote when unspecified\n\nHistorically, we used hardcoded \"origin\" as the fallback default for\ncommands that take a remote (e.g. \"git fetch\") when the user did not\ntell us otherwise.  Since the \"--origin=name\" option was taught to\n\"git clone\", however, we may not have a remote whose name is\n\"origin\" at all.\n\nWhich means that the name given to \"git clone --origin\" does not\ntruly replace the hardcoded \"origin\". An example of such limitation\nis that \"git fetch\" (no other parameters) would fetch happily from\nthe \"origin\" repository, but in a repository cloned with the custom\nname using \"--origin=name\", \"git fetch\" would not fetch from anywhere\nand instead fail.\n\nWe can fix this by noticing that the repository has one and only one\nremote defined, and use that as a replacement for the hardcoded\n\"origin\".\n\nSigned-off-by: Junio C Hamano <gitster@pobox.com>\n---\n\nThis matters for automation for those who want to use --origin\noption.  Imagine you have multiple bare clones and you wanted to use\ncustom names for 'origin'.  And you want a cron job that goes over\nthese repositories and run \"git fetch\" from their upstream before\nyou come in for work, so that these bare clones can be used as\nclose-by mirrors of their upstream projects.\n\nUnfortunately, that would not work.  If these repositories use\ntheir own nicknames for their upstream that are not \"origin\",\n\n\tfor repo in a b c\n\tdo\n\t\tgit -C $repo fetch\n\tdone\n\nwould just fail.  Of course, you can somehow out-of-band know the\norigin's name for each repo, e.g.\n\n\tfor repoorigin in a:xyzzy b:frotz c:nitfol\n\tdo\n\t\trepo=${repoorigin%:*}\n                origin=${repoorigin#*:}\n\t\tgit -C $repo fetch $origin\n\tdone\n\nbut that is solving a problem that arises only because we are not\ntreating the name given to \"git clone --origin=name\" as a true\nreplacement for the default \"origin\".\n\n remote.c             | 10 +++++++++-\n t/t5512-ls-remote.sh | 10 ++++++++--\n 2 files changed, 17 insertions(+), 3 deletions(-)\n\ndiff --git c/remote.c w/remote.c\nindex dfb863d808..8a2fd1ccc9 100644\n--- c/remote.c\n+++ w/remote.c\n@@ -39,6 +39,8 @@ static int remotes_alloc;\n static int remotes_nr;\n static struct hashmap remotes_hash;\n \n+static const char *default_remote_name;\n+\n static struct branch **branches;\n static int branches_alloc;\n static int branches_nr;\n@@ -460,6 +462,12 @@ static void read_config(void)\n \t}\n \tgit_config(handle_config, NULL);\n \talias_all_urls();\n+\tif (remotes_nr == 1 &&\n+\t    remotes[0]->configured_in_repo &&\n+\t    remotes[0]->url)\n+\t\tdefault_remote_name = remotes[0]->name;\n+\telse\n+\t\tdefault_remote_name = \"origin\";\n }\n \n static int valid_remote_nick(const char *name)\n@@ -483,7 +491,7 @@ const char *remote_for_branch(struct branch *branch, int *explicit)\n \t}\n \tif (explicit)\n \t\t*explicit = 0;\n-\treturn \"origin\";\n+\treturn default_remote_name;\n }\n \n const char *pushremote_for_branch(struct branch *branch, int *explicit)\ndiff --git c/t/t5512-ls-remote.sh w/t/t5512-ls-remote.sh\nindex f53f58895a..aa6f14e8fd 100755\n--- c/t/t5512-ls-remote.sh\n+++ w/t/t5512-ls-remote.sh\n@@ -83,8 +83,14 @@ test_expect_success 'ls-remote --sort=\"-refname\" --tags self' '\n \ttest_cmp expect actual\n '\n \n-test_expect_success 'dies when no remote specified and no default remotes found' '\n-\ttest_must_fail git ls-remote\n+test_expect_success 'ls-remote falls back to the only remote' '\n+\tgenerate_references \\\n+\t\trefs/tags/mark1.2 \\\n+\t\trefs/tags/mark1.10 \\\n+\t\trefs/tags/mark1.1 \\\n+\t\trefs/tags/mark >expect &&\n+\tgit ls-remote --sort=\"-refname\" --tags >actual &&\n+\ttest_cmp expect actual\n '\n \n test_expect_success 'use \"origin\" when no remote specified' '\n"},{"id":"432264","messageId":"YQ87eMDaZmeUTmyN@isis.sigpipe.cz","threadId":"56192","inReplyTo":"xmqq4kc0j4cd.fsf_-_@gitster.g","subject":"Re: Re* [PATCH v2] clone: Allow combining --bare and --origin","fromName":"Roman Neuhauser","fromEmail":"rn+git@sigpipe.cz","sentAt":"2021-08-08T02:03:36Z","receivedAt":"2021-08-08T02:03:41Z","isPatch":true,"sender":{"key":"rn+git@sigpipe.cz","avatar":null},"body":"# gitster@pobox.com / 2021-08-07 15:08:02 -0700:\n> Subject: [PATCH] remote: fall back on the sole remote when unspecified\n> \n> Historically, we used hardcoded \"origin\" as the fallback default for\n> commands that take a remote (e.g. \"git fetch\") when the user did not\n> tell us otherwise.  Since the \"--origin=name\" option was taught to\n> \"git clone\", however, we may not have a remote whose name is\n> \"origin\" at all.\n> \n> Which means that the name given to \"git clone --origin\" does not\n> truly replace the hardcoded \"origin\". An example of such limitation\n> is that \"git fetch\" (no other parameters) would fetch happily from\n> the \"origin\" repository, but in a repository cloned with the custom\n> name using \"--origin=name\", \"git fetch\" would not fetch from anywhere\n> and instead fail.\n\nhey, i'm all for all this pre-existing lossage getting fixed if you\ncan do it.  all i'm saying is that since this combination of options\nwasn't possible before there won't be any pre-existing uses of git\nsuddenly breaking.\n\n> This matters for automation for those who want to use --origin\n> option.  Imagine you have multiple bare clones and you wanted to use\n> custom names for 'origin'.  And you want a cron job that goes over\n> these repositories and run \"git fetch\" from their upstream before\n> you come in for work, so that these bare clones can be used as\n> close-by mirrors of their upstream projects.\n\nimagine that you wanted to use git clone --bare --origin with\nany git version released so far.  this is not snark, i'm pointing\nout that git git has a history of things not working where one\nwould expect them to.\n \n> Unfortunately, that would not work.  If these repositories use\n> their own nicknames for their upstream that are not \"origin\",\n> \n> \tfor repo in a b c\n> \tdo\n> \t\tgit -C $repo fetch\n> \tdone\n\n  for repo in a b c; do\n    git -C $repo fetch --all # or git -C remote update\n  done\n\nall it takes to mitigate this is to point this out in the release\nnotes and man page.  what you sketched out above is analogous to my\ninitial encounter with git clone --bare --origin not working:\nwhere were you when the half-assed implementation was landing?  :)\nwhy was there no one to champion for people who'd want to use those\ntwo together? :)) (j/k)\n \n> would just fail.  Of course, you can somehow out-of-band know the\n> origin's name for each repo, e.g.\n\neven if i accept the premise that git fetch --all can't be used\nand the explicit name is necessary, isn't that magical out-of-band\nwand called git-config?\n\n  origin=$(\n    git config --file $repo \\\n    --name-only --get-regexp \\\n    '^remote\\.[^.]*.url' |\n    sed -E 's/^remote\\.([^.]+).url$/\\1/'\n  )\n  git -C $repo fetch $origin\n \ni'm not skilled enough in git-config to simplify that.\n\n\ni think it'd be prudent to pause this thread for now because it's\nonly distracting you from fixing the --origin fallout, and as long\nas you talk about how it *should* be while i bring up available\nworkarounds, it's just noise.\n\n> but that is solving a problem that arises only because we are not\n> treating the name given to \"git clone --origin=name\" as a true\n> replacement for the default \"origin\".\n\nand i'm really grateful that you're tying the loose ends, as long\nas this whole thing doesn't fizzle out on account of being too much,\nand the partial improvement doesn't get swept with it!\n \ni think i said in earlier that i'm a big fan of stripping \"origin\"\nof its special standing.  huge kudos if you can see this through.\n\n-- \nroman\n"}]}