{"thread":{"id":"7161","subject":"[PATCH] git-parse-remote: Support dummy remote `.' in branch.<name>.remote","startedAt":"2007-03-09T15:53:00Z","lastAt":"2007-03-12T08:38:44Z","messageCount":3,"participants":["Paolo Bonzini","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"36679","messageId":"45F182DC.9090507@lu.unisi.ch","threadId":"7161","inReplyTo":null,"subject":"[PATCH] git-parse-remote: Support dummy remote `.' in branch.<name>.remote","fromName":"Paolo Bonzini","fromEmail":"paolo.bonzini@lu.unisi.ch","sentAt":"2007-03-09T15:53:00Z","receivedAt":"2007-03-09T15:53:00Z","isPatch":true,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"This patch adds support for a dummy remote `.' to avoid having to declare\na fake remote like\n\n\t[remote \"local\"]\n\t\turl = .\n\t\tfetch = refs/heads/*:refs/heads/*\n\nA configuration variable is provided, \"branch.forcelocalupdates\", which\nfakes the fetch line to read \"+refs/heads/*:refs/heads/*\".\n\nA subsequent patch, which will be submitted after this and the\n--track/--no-track patch goes in, will add support for the `.'\nremote in `git-branch --track'.\n\nIt is important to notice that the `.' remote only works in\nbranch.<name>.remote by design.\n\nSigned-off-by: Paolo Bonzini  <bonzini@gnu.org>\n---\n Documentation/config.txt |   10 ++++++++++\n git-parse-remote.sh      |   15 ++++++++++++++-\n t/t5520-pull.sh          |   13 +++++++++++++\n 3 files changed, 37 insertions(+), 1 deletion(-)\n\n\tAndy Parkins wrote:\n\n\t> I think what you want is something that I would like too.  If you specify \".\" \n\t> to a git-pull it means to use the local repository not a remote.  It would be \n\t> great if one could have:\n\t> \n\t> [remote \"origin\"]\n        > url = git://git.kernel.org/pub/scm/git/git.git\n        > fetch = refs/heads/master:refs/remotes/origin/master\n\t> [branch \"master\"]\n        > remote = .\n        > merge = refs/remotes/origin/master\n\t>\n\t> That way a \"git pull\" on master wouldn't need to make a remote connection in \n\t> order to do a merge (which is the way I like it).  However, I remember there \n\t> was a reason this wouldn't work, but I don't remember what it was  :-) \n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 5408dd6..0e72c3e 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -272,6 +272,16 @@ branch.<name>.merge::\n \t`git fetch`) to lookup the default branch for merging. Without\n \tthis option, `git pull` defaults to merge the first refspec fetched.\n \tSpecify multiple values to get an octopus merge.\n+\tIf you wish to setup `git pull` so that it merges into <name> from\n+\tanother branch in the local repository, you can point\n+\tbranch.<name>.merge to the desired branch, and use the special setting\n+\t`.` (a period) for branch.<name>.remote.\n+\n+branch.forcelocalupdates::\n+\tIf set to true, merges from the local repository (i.e. when\n+\tbranch.<name>.remote is the special setting `.`) are performed\n+\teven if they do not result in a fast forward update.  The default\n+\tis true.\n \n color.branch::\n \tA boolean to enable/disable color in the output of\ndiff --git a/git-parse-remote.sh b/git-parse-remote.sh\nindex 99e7184..60c4b08 100755\n--- a/git-parse-remote.sh\n+++ b/git-parse-remote.sh\n@@ -9,6 +9,9 @@ get_data_source () {\n \t*/*)\n \t\techo ''\n \t\t;;\n+\t.)\n+\t\techo builtin\n+\t\t;;\n \t*)\n \t\tif test \"$(git-config --get \"remote.$1.url\")\"\n \t\tthen\n@@ -31,6 +34,9 @@ get_remote_url () {\n \t'')\n \t\techo \"$1\"\n \t\t;;\n+\tbuiltin)\n+\t\techo \"$1\"\n+\t\t;;\n \tconfig)\n \t\tgit-config --get \"remote.$1.url\"\n \t\t;;\n@@ -57,7 +63,7 @@ get_default_remote () {\n get_remote_default_refs_for_push () {\n \tdata_source=$(get_data_source \"$1\")\n \tcase \"$data_source\" in\n-\t'' | branches)\n+\t'' | branches | builtin)\n \t\t;; # no default push mapping, just send matching refs.\n \tconfig)\n \t\tgit-config --get-all \"remote.$1.push\" ;;\n@@ -128,6 +134,13 @@ get_remote_default_refs_for_fetch () {\n \tcase \"$data_source\" in\n \t'')\n \t\tset explicit \"HEAD:\" ;;\n+\tbuiltin)\n+\t\tif test $(git-config --bool \"branch.forcelocalupdates\" || echo true) = true\n+\t\tthen\n+\t\t\tset $(expand_refs_wildcard . +refs/heads/*:refs/heads/*)\n+\t\telse\n+\t\t\tset $(expand_refs_wildcard . refs/heads/*:refs/heads/*)\n+\t\tfi ;;\n \tconfig)\n \t\tset $(expand_refs_wildcard \"$1\" \\\n \t\t\t$(git-config --get-all \"remote.$1.fetch\")) ;;\ndiff --git a/t/t5520-pull.sh b/t/t5520-pull.sh\nindex 7eb3783..c424e5b 100755\n--- a/t/t5520-pull.sh\n+++ b/t/t5520-pull.sh\n@@ -29,5 +29,18 @@ test_expect_success 'checking the results' '\n \tdiff file cloned/file\n '\n \n+test_expect_success 'test . as a remote' '\n+\n+\tgit branch copy master &&\n+\tgit config branch.copy.remote . &&\n+\tgit config branch.copy.merge refs/heads/master &&\n+\techo updated >file &&\n+\tgit commit -a -m updated &&\n+\tgit checkout copy &&\n+\ttest `cat file` = file &&\n+\tgit pull &&\n+\ttest `cat file` = updated\n+'\n+\n test_done\n \n"},{"id":"36703","messageId":"7v1wjy3qas.fsf@assigned-by-dhcp.cox.net","threadId":"7161","inReplyTo":"45F182DC.9090507@lu.unisi.ch","subject":"Re: [PATCH] git-parse-remote: Support dummy remote `.' in branch.<name>.remote","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-03-10T00:17:31Z","receivedAt":"2007-03-10T00:17:31Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Paolo Bonzini <paolo.bonzini@lu.unisi.ch> writes:\n\n> This patch adds support for a dummy remote `.' to avoid having to declare\n> a fake remote like\n>\n> \t[remote \"local\"]\n> \t\turl = .\n> \t\tfetch = refs/heads/*:refs/heads/*\n\nFor one thing, I do not think it would help Andy's original\nexample of reusing what we already have in refs/remotes\nhierarchy if you faked it with refs/heads/*:refs/heads/*\nwildcard like the above.\n\nWhy not\n\n\t[remote \"local\"]\n        \turl = .\n                fetch = refs/heads/*\n\nor even\n\n\t[remote \"local\"]\n        \turl = .\n                fetch = refs/*\n\nexcept that we currently do not have non-storing globbing\npattern defined?\n\nI am actually Ok with the idea of built-in \".\", but I really do\nnot like it to even pretend storing the fetched results in local\nbranches.  If you stop thinking in terms of \"tracking fetch\"\nthat stores the result in some local branch, you do not have to\nhave branch.forcelocalupdates.\n\nBy the way, I do not understand the semantics of that\nconfiguration variable at all.\n\n> +branch.forcelocalupdates::\n> +\tIf set to true, merges from the local repository (i.e. when\n> +\tbranch.<name>.remote is the special setting `.`) are performed\n> +\teven if they do not result in a fast forward update.  The default\n> +\tis true.\n\nReally, when does fetching from refs/heads/<blah> into refs/heads/<blah>\nresult in anything but \"already up-to-date\"?\n\nI think you can get rid of this ridiculous \"we obtain\nrefs/heads/master from ourselves and store it in the same branch\nof ours\".  The only thing you want here is to leave FETCH_HEAD\nin a state that is usable by git-pull.  Wouldn't that be much\ncleaner?\n\n> @@ -128,6 +134,13 @@ get_remote_default_refs_for_fetch () {\n>  \tcase \"$data_source\" in\n>  \t'')\n>  \t\tset explicit \"HEAD:\" ;;\n> +\tbuiltin)\n> +\t\tif test $(git-config --bool \"branch.forcelocalupdates\" || echo true) = true\n> +\t\tthen\n> +\t\t\tset $(expand_refs_wildcard . +refs/heads/*:refs/heads/*)\n> +\t\telse\n> +\t\t\tset $(expand_refs_wildcard . refs/heads/*:refs/heads/*)\n> +\t\tfi ;;\n>  \tconfig)\n>  \t\tset $(expand_refs_wildcard \"$1\" \\\n>  \t\t\t$(git-config --get-all \"remote.$1.fetch\")) ;;\n\nEspecially this above hunk is not something I'd like to see so\nthe patch won't be applied as-is in this round, but just for\nfuture reference...\n\nThe --bool option makes sure the git-config command either says\n\"true\", \"false\" or silently exit with non-zero, in which case\nyou would let echo say \"true\".  In that sense, it is not a\nproblem in this particular patch, but in general it makes me\nworried when I see somebody feeds $() without quoting to test as\nits argument.\n"},{"id":"36893","messageId":"45F51194.5090106@lu.unisi.ch","threadId":"7161","inReplyTo":"7v1wjy3qas.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] git-parse-remote: Support dummy remote `.' in branch.<name>.remote","fromName":"Paolo Bonzini","fromEmail":"paolo.bonzini@lu.unisi.ch","sentAt":"2007-03-12T08:38:44Z","receivedAt":"2007-03-12T08:38:44Z","isPatch":true,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"\n> By the way, I do not understand the semantics of that\n> configuration variable at all.\n\nI think I seriously misunderstood something -- I cannot even\nrecall what -- when I wrote that.  In fact, the only thing I\nwant to work, is the scenario for which I wrote the testcase.\n\nI'll ponder your comments on FETCH_HEAD and see if I can write\nthe patch in a better way.\n\nPaolo\n"}]}