{"thread":{"id":"33834","subject":"[PATCH 0/3] fetch: fix '.' fetching","startedAt":"2013-05-16T07:31:11Z","lastAt":"2013-05-19T14:27:38Z","messageCount":31,"participants":["Felipe Contreras","Ramkumar Ramachandra","Junio C Hamano","Philip Oakley"],"isPatch":true,"patchVersion":1,"patchTotal":3},"messages":[{"id":"217513","messageId":"1368689474-28911-1-git-send-email-felipe.contreras@gmail.com","threadId":"33834","inReplyTo":null,"subject":"[PATCH 0/3] fetch: fix '.' fetching","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-05-16T07:31:11Z","receivedAt":"2013-05-16T07:31:11Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Hi,\n\nIt's quite annoying that 'git fetch' tries to fetch '.' when the upstream\nbranch is a local one. This patch series fixes that, and while on it, it also\nfixes 'git push'.\n\nFelipe Contreras (3):\n fetch: add --allow-local option\n fetch: switch allow-local off by default\n remote: disable allow-local for pushes\n\n builtin/fetch.c | 6 +++++-\n git-pull.sh | 2 +-\n remote.c | 17 ++++++++++++++---\n remote.h | 1 +\n t/t5513-fetch-track.sh | 14 ++++++++++++++\n t/t5528-push-default.sh | 7 +++++++\n 6 files changed, 42 insertions(+), 5 deletions(-)\n\n-- \n1.8.3.rc1.579.g184e698\n"},{"id":"217514","messageId":"1368689474-28911-2-git-send-email-felipe.contreras@gmail.com","threadId":"33834","inReplyTo":"1368689474-28911-1-git-send-email-felipe.contreras@gmail.com","subject":"[PATCH 1/3] fetch: add --allow-local option","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-05-16T07:31:12Z","receivedAt":"2013-05-16T07:31:12Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"So that it becomes possible to override the behavior when the remote\ntracked is '.'; if it is, we default back to 'origin'.\n\nTo do this, we need to add a new helper fetchremote_get() that accepts\nthe boolean to enable/disable this behavior.\n\nThe default is 'true' which shouldn't cause any change in behavior.\n\nSigned-off-by: Felipe Contreras \n---\n builtin/fetch.c | 6 +++++-\n remote.c | 17 ++++++++++++++---\n remote.h | 1 +\n 3 files changed, 20 insertions(+), 4 deletions(-)\n\ndiff --git a/builtin/fetch.c b/builtin/fetch.c\nindex 4b6b1df..2efbd7b 100644\n--- a/builtin/fetch.c\n+++ b/builtin/fetch.c\n@@ -39,6 +39,7 @@ static struct strbuf default_rla = STRBUF_INIT;\n static struct transport *transport;\n static const char *submodule_prefix = \"\";\n static const char *recurse_submodules_default;\n+static int allow_local = 1;\n \n static int option_parse_recurse_submodules(const struct option *opt,\n \t\t\t\t const char *arg, int unset)\n@@ -90,6 +91,9 @@ static struct option builtin_fetch_options[] = {\n \t{ OPTION_STRING, 0, \"recurse-submodules-default\",\n \t\t &recurse_submodules_default, NULL,\n \t\t N_(\"default mode for recursion\"), PARSE_OPT_HIDDEN },\n+\t{ OPTION_SET_INT, 0, \"allow-local\", &allow_local, NULL,\n+\t\t N_(\"allow fetching from local repository\"),\n+\t\t PARSE_OPT_NOARG | PARSE_OPT_HIDDEN, NULL, 1 },\n \tOPT_END()\n };\n \n@@ -1006,7 +1010,7 @@ int cmd_fetch(int argc, const char **argv, const char *prefix)\n \t\tresult = fetch_multiple(&list);\n \t} else if (argc == 0) {\n \t\t/* No arguments -- use default remote */\n-\t\tremote = remote_get(NULL);\n+\t\tremote = fetchremote_get(NULL, allow_local);\n \t\tresult = fetch_one(remote, argc, argv);\n \t} else if (multiple) {\n \t\t/* All arguments are assumed to be remotes or groups */\ndiff --git a/remote.c b/remote.c\nindex 68eb99b..a7e59ab 100644\n--- a/remote.c\n+++ b/remote.c\n@@ -682,7 +682,7 @@ static int valid_remote_nick(const char *name)\n \treturn !strchr(name, '/'); /* no slash */\n }\n \n-static struct remote *remote_get_1(const char *name, const char *pushremote_name)\n+static struct remote *remote_get_1(const char *name, const char *pushremote_name, int allow_local)\n {\n \tstruct remote *ret;\n \tint name_given = 0;\n@@ -699,6 +699,11 @@ static struct remote *remote_get_1(const char *name, const char *pushremote_name\n \t\t}\n \t}\n \n+\tif (!allow_local && !strcmp(name, \".\")) {\n+\t\tname = \"origin\";\n+\t\tname_given = 0;\n+\t}\n+\n \tret = make_remote(name, 0);\n \tif (valid_remote_nick(name)) {\n \t\tif (!valid_remote(ret))\n@@ -718,13 +723,19 @@ static struct remote *remote_get_1(const char *name, const char *pushremote_name\n struct remote *remote_get(const char *name)\n {\n \tread_config();\n-\treturn remote_get_1(name, NULL);\n+\treturn remote_get_1(name, NULL, 1);\n }\n \n struct remote *pushremote_get(const char *name)\n {\n \tread_config();\n-\treturn remote_get_1(name, pushremote_name);\n+\treturn remote_get_1(name, pushremote_name, 1);\n+}\n+\n+struct remote *fetchremote_get(const char *name, int allow_local)\n+{\n+\tread_config();\n+\treturn remote_get_1(name, NULL, allow_local);\n }\n \n int remote_is_configured(const char *name)\ndiff --git a/remote.h b/remote.h\nindex cf56724..f0d6cf3 100644\n--- a/remote.h\n+++ b/remote.h\n@@ -52,6 +52,7 @@ struct remote {\n \n struct remote *remote_get(const char *name);\n struct remote *pushremote_get(const char *name);\n+struct remote *fetchremote_get(const char *name, int allow_local);\n int remote_is_configured(const char *name);\n \n typedef int each_remote_fn(struct remote *remote, void *priv);\n-- \n1.8.3.rc1.579.g184e698\n"},{"id":"217515","messageId":"1368689474-28911-3-git-send-email-felipe.contreras@gmail.com","threadId":"33834","inReplyTo":"1368689474-28911-1-git-send-email-felipe.contreras@gmail.com","subject":"[PATCH 2/3] fetch: switch allow-local off by default","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-05-16T07:31:13Z","receivedAt":"2013-05-16T07:31:13Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"And force it on in 'git push' to retain the old behavior.\n\nSigned-off-by: Felipe Contreras \n---\n builtin/fetch.c | 2 +-\n git-pull.sh | 2 +-\n t/t5513-fetch-track.sh | 14 ++++++++++++++\n 3 files changed, 16 insertions(+), 2 deletions(-)\n\ndiff --git a/builtin/fetch.c b/builtin/fetch.c\nindex 2efbd7b..c65c75b 100644\n--- a/builtin/fetch.c\n+++ b/builtin/fetch.c\n@@ -39,7 +39,7 @@ static struct strbuf default_rla = STRBUF_INIT;\n static struct transport *transport;\n static const char *submodule_prefix = \"\";\n static const char *recurse_submodules_default;\n-static int allow_local = 1;\n+static int allow_local = 0;\n \n static int option_parse_recurse_submodules(const struct option *opt,\n \t\t\t\t const char *arg, int unset)\ndiff --git a/git-pull.sh b/git-pull.sh\nindex 638aabb..18c3793 100755\n--- a/git-pull.sh\n+++ b/git-pull.sh\n@@ -220,7 +220,7 @@ test true = \"$rebase\" && {\n \tdone\n }\n orig_head=$(git rev-parse -q --verify HEAD)\n-git fetch $verbosity $progress $dry_run $recurse_submodules --update-head-ok \"$@\" || exit 1\n+git fetch $verbosity $progress $dry_run $recurse_submodules --update-head-ok --allow-local \"$@\" || exit 1\n test -z \"$dry_run\" || exit 0\n \n curr_head=$(git rev-parse -q --verify HEAD)\ndiff --git a/t/t5513-fetch-track.sh b/t/t5513-fetch-track.sh\nindex 65d1e05..cb46747 100755\n--- a/t/t5513-fetch-track.sh\n+++ b/t/t5513-fetch-track.sh\n@@ -27,4 +27,18 @@ test_expect_success fetch '\n \t)\n '\n \n+test_expect_success 'fetch no-local' '\n+\t(\n+\t\ttest_create_repo another &&\n+\t\tcd another &&\n+\t\tgit remote add origin .. &&\n+\t\techo test > file &&\n+\t\tgit add . &&\n+\t\tgit commit -m test &&\n+\t\tgit checkout -t -b local-tracking master &&\n+\t\tgit fetch &&\n+\t\tgit rev-parse --verify refs/remotes/origin/b/one\n+\t)\n+'\n+\n test_done\n-- \n1.8.3.rc1.579.g184e698\n"},{"id":"217516","messageId":"1368689474-28911-4-git-send-email-felipe.contreras@gmail.com","threadId":"33834","inReplyTo":"1368689474-28911-1-git-send-email-felipe.contreras@gmail.com","subject":"[PATCH 3/3] remote: disable allow-local for pushes","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-05-16T07:31:14Z","receivedAt":"2013-05-16T07:31:14Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"So that 'git push' uses 'origin', instead of '.' by default.\n\nSigned-off-by: Felipe Contreras \n---\n remote.c | 2 +-\n t/t5528-push-default.sh | 7 +++++++\n 2 files changed, 8 insertions(+), 1 deletion(-)\n\ndiff --git a/remote.c b/remote.c\nindex a7e59ab..c1458dc 100644\n--- a/remote.c\n+++ b/remote.c\n@@ -729,7 +729,7 @@ struct remote *remote_get(const char *name)\n struct remote *pushremote_get(const char *name)\n {\n \tread_config();\n-\treturn remote_get_1(name, pushremote_name, 1);\n+\treturn remote_get_1(name, pushremote_name, 0);\n }\n \n struct remote *fetchremote_get(const char *name, int allow_local)\ndiff --git a/t/t5528-push-default.sh b/t/t5528-push-default.sh\nindex 4736da8..61df2a7 100755\n--- a/t/t5528-push-default.sh\n+++ b/t/t5528-push-default.sh\n@@ -115,4 +115,11 @@ test_expect_success 'push to existing branch, upstream configured with different\n \ttest_cmp expect-other-name actual-other-name\n '\n \n+test_expect_success 'push to existing branch, upstream configured with same name' '\n+\tgit remote add origin repo1 &&\n+\tgit checkout -t -b local-tracking master &&\n+\ttest_commit ten &&\n+\ttest_push_success current local-tracking\n+'\n+\n test_done\n-- \n1.8.3.rc1.579.g184e698\n"},{"id":"217526","messageId":"CALkWK0=OTBVauqpxZO5br5zRy8D_o3DzgLfaDRVx9Y_EVm19qA@mail.gmail.com","threadId":"33834","inReplyTo":"1368689474-28911-2-git-send-email-felipe.contreras@gmail.com","subject":"Re: [PATCH 1/3] fetch: add --allow-local option","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-05-16T08:25:24Z","receivedAt":"2013-05-16T08:25:24Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Felipe Contreras wrote:\n> So that it becomes possible to override the behavior when the remote\n> tracked is '.'; if it is, we default back to 'origin'.\n\nWhat is the problem you're trying to solve? Why do you have\nbranch..remote set to '.' in the first place, if you meant\norigin? 'git fetch .' currently just updates FETCH_HEAD; while I'm\nnot sure how that is useful, I still don't understand _why_ you want\nto change that behavior.\n"},{"id":"217539","messageId":"CAMP44s1SWORAzBP-WO_Xc62F=YFckgU4knLyse0DSDRW33crZA@mail.gmail.com","threadId":"33834","inReplyTo":"CALkWK0=OTBVauqpxZO5br5zRy8D_o3DzgLfaDRVx9Y_EVm19qA@mail.gmail.com","subject":"Re: [PATCH 1/3] fetch: add --allow-local option","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-05-16T08:53:46Z","receivedAt":"2013-05-16T08:53:46Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, May 16, 2013 at 3:25 AM, Ramkumar Ramachandra\n wrote:\n> Felipe Contreras wrote:\n>> So that it becomes possible to override the behavior when the remote\n>> tracked is '.'; if it is, we default back to 'origin'.\n>\n> What is the problem you're trying to solve? Why do you have\n> branch..remote set to '.' in the first place, if you meant\n> origin? 'git fetch .' currently just updates FETCH_HEAD; while I'm\n> not sure how that is useful, I still don't understand _why_ you want\n> to change that behavior.\n\n% git checkout -t -b devel master\n\n-- \nFelipe Contreras\n"},{"id":"217549","messageId":"CALkWK0nT7fySb5um1RcKW2R4v6AE_EQ0gTod8_kNNJOFbwFnWQ@mail.gmail.com","threadId":"33834","inReplyTo":"CAMP44s1SWORAzBP-WO_Xc62F=YFckgU4knLyse0DSDRW33crZA@mail.gmail.com","subject":"Re: [PATCH 1/3] fetch: add --allow-local option","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-05-16T09:27:28Z","receivedAt":"2013-05-16T09:27:28Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Felipe Contreras wrote:\n> % git checkout -t -b devel master\n\nInteresting. Have you considered changing -t to inherit the parent\nbranch's remote? (Would everyone like that?)\n"},{"id":"217551","messageId":"CAMP44s0x62h+n29osEdRvuhBtvDY7bD3m1_jDq4ZDMrgFwP0ow@mail.gmail.com","threadId":"33834","inReplyTo":"CALkWK0nT7fySb5um1RcKW2R4v6AE_EQ0gTod8_kNNJOFbwFnWQ@mail.gmail.com","subject":"Re: [PATCH 1/3] fetch: add --allow-local option","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-05-16T09:34:41Z","receivedAt":"2013-05-16T09:34:41Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, May 16, 2013 at 4:27 AM, Ramkumar Ramachandra\n wrote:\n> Felipe Contreras wrote:\n>> % git checkout -t -b devel master\n>\n> Interesting. Have you considered changing -t to inherit the parent\n> branch's remote? (Would everyone like that?)\n\nWhy would I do that? When I do 'git rebase' I want to rebase on top of\n'master', not 'origin/master' (or whatever the upstream of 'master'\nis).\n\n-- \nFelipe Contreras\n"},{"id":"217571","messageId":"CALkWK0kwia-OQj_=B7A3k6_DxCJShqoJehNQu8eApgdo=OzQwg@mail.gmail.com","threadId":"33834","inReplyTo":"CAMP44s0x62h+n29osEdRvuhBtvDY7bD3m1_jDq4ZDMrgFwP0ow@mail.gmail.com","subject":"Re: [PATCH 1/3] fetch: add --allow-local option","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-05-16T09:58:57Z","receivedAt":"2013-05-16T09:58:57Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Felipe Contreras wrote:\n> Why would I do that? When I do 'git rebase' I want to rebase on top of\n> 'master', not 'origin/master' (or whatever the upstream of 'master'\n> is).\n\nAh, so you want @{u} to point to refs/heads/master, but want to modify\nfetch to act on the hard-coded \"origin\", not @{u} (wouldn't you like\nto be able to configure this?). Seems a bit yuck overall; I wonder if\nthere's some other way to achieve what you want.\n"},{"id":"217578","messageId":"CAMP44s03C2Wi5Bwma2wK5jMisBCyBaOVQ8UXuPaec9f27A0RvQ@mail.gmail.com","threadId":"33834","inReplyTo":"CALkWK0kwia-OQj_=B7A3k6_DxCJShqoJehNQu8eApgdo=OzQwg@mail.gmail.com","subject":"Re: [PATCH 1/3] fetch: add --allow-local option","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-05-16T10:27:34Z","receivedAt":"2013-05-16T10:27:34Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, May 16, 2013 at 4:58 AM, Ramkumar Ramachandra\n wrote:\n> Felipe Contreras wrote:\n>> Why would I do that? When I do 'git rebase' I want to rebase on top of\n>> 'master', not 'origin/master' (or whatever the upstream of 'master'\n>> is).\n>\n> Ah, so you want @{u} to point to refs/heads/master, but want to modify\n> fetch to act on the hard-coded \"origin\", not @{u} (wouldn't you like\n> to be able to configure this?).\n\nNo. What's the point of 'git fetch .'? What does 'git fetch' does when\nthere's no configured upstream branch? Why doesn't 'git fetch' default\nto 'git fetch .' in those cases?\n\nAnswer: because 'git fetch .' doesn't make any sense. So if\n'branch.HEAD.remote' is '.' it doesn't make sense to do 'git fetch .'.\n\n> Seems a bit yuck overall; I wonder if\n> there's some other way to achieve what you want.\n\nYeah, add 'branch.A.base' that would be used only by 'git rebase',\nwhich I already suggested before, but I changed my mind.\n\nFixing 'git fetch' makes much more sense.\n\n-- \nFelipe Contreras\n"},{"id":"217579","messageId":"CALkWK0m=-ePHCLChrBSgD_cUk=MOSt15aYf-yXhn_LpDro88fw@mail.gmail.com","threadId":"33834","inReplyTo":"CAMP44s03C2Wi5Bwma2wK5jMisBCyBaOVQ8UXuPaec9f27A0RvQ@mail.gmail.com","subject":"Re: [PATCH 1/3] fetch: add --allow-local option","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-05-16T10:32:36Z","receivedAt":"2013-05-16T10:32:36Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Felipe Contreras wrote:\n> Answer: because 'git fetch .' doesn't make any sense. So if\n> 'branch.HEAD.remote' is '.' it doesn't make sense to do 'git fetch .'.\n\nI agree that 'git fetch .' is currently not useful (and I am not\nagainst changing its behavior), but my question pertains to why you\nare replacing it with the hard-coded \"origin\". What happens when I\ngit branch -t -b devel hot-branch where branch.hot-branch.remote = ram\nand not origin?\n"},{"id":"217587","messageId":"CAMP44s2Wf7ZfmQ-7UGy2fNRX3TXaRMDu3WtZzz-WEOHibRAWVA@mail.gmail.com","threadId":"33834","inReplyTo":"CALkWK0m=-ePHCLChrBSgD_cUk=MOSt15aYf-yXhn_LpDro88fw@mail.gmail.com","subject":"Re: [PATCH 1/3] fetch: add --allow-local option","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-05-16T12:54:12Z","receivedAt":"2013-05-16T12:54:12Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, May 16, 2013 at 5:32 AM, Ramkumar Ramachandra\n wrote:\n> Felipe Contreras wrote:\n>> Answer: because 'git fetch .' doesn't make any sense. So if\n>> 'branch.HEAD.remote' is '.' it doesn't make sense to do 'git fetch .'.\n>\n> I agree that 'git fetch .' is currently not useful (and I am not\n> against changing its behavior), but my question pertains to why you\n> are replacing it with the hard-coded \"origin\".\n\n'origin' is already hard-coded.\n\n% git clone git://git.kernel.org/pub/scm/git/git.git\n\nWhat would be the name of the remote? 'origin'.\n\n% git checkout --no-track -b test\n% git fetch\n\nWhat is the remote that is used? 'origin'.\n\n> What happens when I\n> git branch -t -b devel hot-branch where branch.hot-branch.remote = ram\n> and not origin?\n\nThe same thing that happens when you git branch --no-track -b devel hot-branch.\n\n-- \nFelipe Contreras\n"},{"id":"217614","messageId":"7v61yi9arl.fsf@alter.siamese.dyndns.org","threadId":"33834","inReplyTo":"1368689474-28911-2-git-send-email-felipe.contreras@gmail.com","subject":"Re: [PATCH 1/3] fetch: add --allow-local option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-05-16T15:58:54Z","receivedAt":"2013-05-16T15:58:54Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> So that it becomes possible to override the behavior when the remote\n> tracked is '.'; if it is, we default back to 'origin'.\n\nI know I was the stupid one who originally suggested this, but I\nthink this is a wrong direction to go. I do not think it solves\nyour \"I do not want to say 'git fetch origin'\" problem.\n\nYou do \"git checkout -t -b mywork master\" because you want to later\nbe able to conveniently rebase mywork on top of your local master\n(i.e. make @{u} notation work for you) [*1*].\n\nWhat \"git checkout -t -b $branch $up\" does is to declare that branch\nbuilds on top of $up, which often is some remote tracking branch.\nAnd \"git pull [--rebase]\" on that $branch is to\n\n (1) make sure $up is available and up to date; and\n\n (2) integrate with $up. The first step is \"git fetch\" and it\n has to go to the repository $up comes from.\n\nIf $up is in your local repository (the original \"fork mywork from\nmaster in my repository\"), the first step ought to be a no-op, and\n\"git fetch\" from the current repository may seem wasteful, but I\nthink we already have an optimization to make this no-op not to\ntransfer anything network-wise. There is no justification for it to\ngo to 'origin' or any other random remote that is different from the\nreopsitory $up comes from.\n\nI _think_ the real reason you want a \"git fetch\" while on \"mywork\"\nto go to 'origin' is because you are building your \"master\" off of\nsomebody else's work that comes from 'origin', and you want to check\nwhat has changed to see what you need to rebuild both your \"master\"\nand \"mywork\" branches on top of. If 'master' were forked from a\nremote that is not 'origin', then making \"git fetch\" ignore '.' and\ninstead go to 'origin' would not solve anything. For an updated\nbehaviour to be useful in that workflow, it needs to follow the\ninter-branch relationship (\"mywork is a fork of master which is a\nfork of frotz branch from a remote xyzzy\") to see the first remote\nrepository and fetch from there, instead of blindly fetching from\nthe 'origin'.\n\nHaving said all that, I am not all that sure that it is a good idea\nto introduce such an exception for \"git fetch\" to ignore '.',\nregardless of where it goes instead, either the 'origin' or the\nfirst remote repository it finds by recursively finding its\nupstreams, to break the consistency at the UI level. It is dubious\nif the benefit of convenience to fetch from remote 'xyzzy' that is\nan eventual remote of 'mywork' without having to say so outweighs\nthe cost of additional UI inconsistency, making things harder to\nexplain to both new and old people.\n\n\n[Footnote]\n\n*1* Another side effect this has is that in a triangular workflow,\n the place you push to may not be the place the branch you\n integrate with (i.e. 'master') lives (i.e. '.', your local\n repository), and the name you want to push it as may not be the\n same as the branch you integrate with (i.e. 'master'), either.\n\n Ram's branch.mywork.pushremote can solve the former (i.e. where\n it goes), but not the latter (i.e. to which branch it is pushed),\n and that is a valid issue that may need to be addressed.\n"},{"id":"217618","messageId":"CAMP44s14TSGtQ7kvWUgrOQvT1uKciSV5fd5pQvy1ven8Z=qVcg@mail.gmail.com","threadId":"33834","inReplyTo":"7v61yi9arl.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 1/3] fetch: add --allow-local option","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-05-16T16:26:19Z","receivedAt":"2013-05-16T16:26:19Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, May 16, 2013 at 10:58 AM, Junio C Hamano wrote:\n\n> I _think_ the real reason you want a \"git fetch\" while on \"mywork\"\n> to go to 'origin' is because you are building your \"master\" off of\n> somebody else's work that comes from 'origin', and you want to check\n> what has changed to see what you need to rebuild both your \"master\"\n> and \"mywork\" branches on top of. If 'master' were forked from a\n> remote that is not 'origin', then making \"git fetch\" ignore '.' and\n> instead go to 'origin' would not solve anything. For an updated\n> behaviour to be useful in that workflow, it needs to follow the\n> inter-branch relationship (\"mywork is a fork of master which is a\n> fork of frotz branch from a remote xyzzy\") to see the first remote\n> repository and fetch from there, instead of blindly fetching from\n> the 'origin'.\n\nNo, the reason I want 'git fetch' to fetch 'origin' is because it has\nalways done so. It only stopped doing so when I configured 'upstream'\nbranches. I'm not even sure I want 'git fetch' to fetch from the\nremote of my current branch if it has an upstream branch.\n\n> Having said all that, I am not all that sure that it is a good idea\n> to introduce such an exception for \"git fetch\" to ignore '.',\n> regardless of where it goes instead, either the 'origin' or the\n> first remote repository it finds by recursively finding its\n> upstreams, to break the consistency at the UI level. It is dubious\n> if the benefit of convenience to fetch from remote 'xyzzy' that is\n> an eventual remote of 'mywork' without having to say so outweighs\n> the cost of additional UI inconsistency, making things harder to\n> explain to both new and old people.\n\nThat doesn't change the fact that 'git fetch .' does not make any\nsense whatsoever. The user *will* get confused when (s)he does 'git\nfetch' and nothing happens. The problem is not solved.\n\n% git checkout -b fixes master\n% git fetch\n% git branch -u master\n% git fetch\n\n# scratch head\n\n-- \nFelipe Contreras\n"},{"id":"217624","messageId":"7v8v3e7udi.fsf@alter.siamese.dyndns.org","threadId":"33834","inReplyTo":"CAMP44s14TSGtQ7kvWUgrOQvT1uKciSV5fd5pQvy1ven8Z=qVcg@mail.gmail.com","subject":"Re: [PATCH 1/3] fetch: add --allow-local option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-05-16T16:38:17Z","receivedAt":"2013-05-16T16:38:17Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> That doesn't change the fact that 'git fetch .' does not make any\n> sense whatsoever. The user *will* get confused when (s)he does 'git\n> fetch' and nothing happens. The problem is not solved.\n>\n> % git checkout -b fixes master\n> % git fetch\n> % git branch -u master\n> % git fetch\n>\n> # scratch head\n\n# reads manual, perhaps?\n\nWhy do you declare without justification that \"git fetch .\" does not\nmake sense? If you come from \"git pull\" is \"git fetch\" + \"git merge\",\nand if your current branch is integrating with your local branch, it\nis natural that \"git fetch\" that does not say where to fetch from\nfetches from your local repository (object-transfer wise, it is a\nno-op) and update FETCH_HEAD. You can say \"it is not necessary, as\nwe can directly go to @{u}\", but that is different from \"it does not\nmake any sense\".\n\nI think the real cause of the problem is that some people advocate\nthe use of \"git fetch\" that does not say \"from where\" and \"get\nwhat\". When the user understand what it does and what it does it\nfor, not having to type is a convenience, but as a recipe to be\nblindly followed, it leaves the new people in the dark.\n"},{"id":"217627","messageId":"CAMP44s0Szu8oHBKMapZ6dQ1K67MXDcACuUF-+Y-jC+EgHs2QEA@mail.gmail.com","threadId":"33834","inReplyTo":"7v8v3e7udi.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 1/3] fetch: add --allow-local option","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-05-16T16:52:53Z","receivedAt":"2013-05-16T16:52:53Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, May 16, 2013 at 11:38 AM, Junio C Hamano wrote:\n> Felipe Contreras writes:\n>\n>> That doesn't change the fact that 'git fetch .' does not make any\n>> sense whatsoever. The user *will* get confused when (s)he does 'git\n>> fetch' and nothing happens. The problem is not solved.\n>>\n>> % git checkout -b fixes master\n>> % git fetch\n>> % git branch -u master\n>> % git fetch\n>>\n>> # scratch head\n>\n> # reads manual, perhaps?\n\nYou expect too much from users. But...\n\n% man git push\n/default\n\nNothing.\n\n> Why do you declare without justification that \"git fetch .\" does not\n> make sense?\n\nWhat does 'git fetch .' do?\n\n> If you come from \"git pull\" is \"git fetch\" + \"git merge\",\n> and if your current branch is integrating with your local branch,\n\nHow many times do I have to say that 'git pull' is not 'git fetch' +\n'git merge'?\n\nYou must think everybody has 'merge.defaulttoupstream=true'.\n\n> it\n> is natural that \"git fetch\" that does not say where to fetch from\n> fetches from your local repository (object-transfer wise, it is a\n> no-op) and update FETCH_HEAD. You can say \"it is not necessary, as\n> we can directly go to @{u}\", but that is different from \"it does not\n> make any sense\".\n\nIt literally does not make any sense. From the point of view of the\ntypical user it does nothing.\n\n> I think the real cause of the problem is that some people advocate\n> the use of \"git fetch\" that does not say \"from where\" and \"get\n> what\". When the user understand what it does and what it does it\n> for, not having to type is a convenience, but as a recipe to be\n> blindly followed, it leaves the new people in the dark.\n\nThat's totally irrelevant. Whether the user knows all the details or\nnot doesn't matter. Typing less is good, and it's important that\ncommands without arguments do something sane, and 'git fetch' doesn't.\nThe user should not be forced to type the remote when it's not\nnecessary, and wasting the 'git fetch' command to do absolutely\nnothing is not smart.\n\n-- \nFelipe Contreras\n"},{"id":"217631","messageId":"7vk3my6bu1.fsf@alter.siamese.dyndns.org","threadId":"33834","inReplyTo":"CAMP44s0Szu8oHBKMapZ6dQ1K67MXDcACuUF-+Y-jC+EgHs2QEA@mail.gmail.com","subject":"Re: [PATCH 1/3] fetch: add --allow-local option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-05-16T18:04:06Z","receivedAt":"2013-05-16T18:04:06Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n>> If you come from \"git pull\" is \"git fetch\" + \"git merge\",\n>> and if your current branch is integrating with your local branch,\n>\n> How many times do I have to say that 'git pull' is not 'git fetch' +\n> 'git merge'?\n>\n> You must think everybody has 'merge.defaulttoupstream=true'.\n\nI am confused. What does that have anything to do with this topic?\nIt only affects what a lazy \"git merge\" (without any other parameter\non the command line) does, doesn't it?\n\nIn the above \"git fetch\" + \"git merge\", I did not mean \"git merge\"\nis literally what the command line of the command invoked\ninternally. \"git pull\" of course chooses what is to be merged.\n\nBut that does not change the fact that before merging (or rebasing,\nif you are running \"git pull --rebase\"), \"git fetch\" is done in\norder to make sure the history you are merging with (or rebasing on\ntop of) is available locally and FETCH_HEAD is prepared so that \"git\npull\" can decide what to merge with (or rebase on). \n\nThe merge.defaultToUpstream configuration does not change that, does\nit?\n"},{"id":"217654","messageId":"CAMP44s2W5MUneTwcSnr=Ey715paKgSL6MqXmYKdSmw4NqdL4qQ@mail.gmail.com","threadId":"33834","inReplyTo":"7vk3my6bu1.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 1/3] fetch: add --allow-local option","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-05-16T23:07:47Z","receivedAt":"2013-05-16T23:07:47Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, May 16, 2013 at 1:04 PM, Junio C Hamano wrote:\n> Felipe Contreras writes:\n>\n>>> If you come from \"git pull\" is \"git fetch\" + \"git merge\",\n>>> and if your current branch is integrating with your local branch,\n>>\n>> How many times do I have to say that 'git pull' is not 'git fetch' +\n>> 'git merge'?\n>>\n>> You must think everybody has 'merge.defaulttoupstream=true'.\n>\n> I am confused. What does that have anything to do with this topic?\n> It only affects what a lazy \"git merge\" (without any other parameter\n> on the command line) does, doesn't it?\n\nAnd that's what we are talking about here; commands without any other\nparameter in the command like.\n\nSo \"git pull $nothing\" is *not* \"git fetch $nothing\" + \"git merge $nothing\".\n\n> In the above \"git fetch\" + \"git merge\", I did not mean \"git merge\"\n> is literally what the command line of the command invoked\n> internally. \"git pull\" of course chooses what is to be merged.\n>\n> But that does not change the fact that before merging (or rebasing,\n> if you are running \"git pull --rebase\"), \"git fetch\" is done in\n> order to make sure the history you are merging with (or rebasing on\n> top of) is available locally and FETCH_HEAD is prepared so that \"git\n> pull\" can decide what to merge with (or rebase on).\n\nWe are not talking about 'git pull .', we are talking about 'git fetch\n.', and it doesn't make any sense.\n\n> The merge.defaultToUpstream configuration does not change that, does\n> it?\n\nIt changes the equation 'git pull' = 'git fetch' + 'git merge'.\n\n-- \nFelipe Contreras\n"},{"id":"217659","messageId":"7vk3my33vb.fsf@alter.siamese.dyndns.org","threadId":"33834","inReplyTo":"CAMP44s2W5MUneTwcSnr=Ey715paKgSL6MqXmYKdSmw4NqdL4qQ@mail.gmail.com","subject":"Re: [PATCH 1/3] fetch: add --allow-local option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-05-16T23:24:24Z","receivedAt":"2013-05-16T23:24:24Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> On Thu, May 16, 2013 at 1:04 PM, Junio C Hamano wrote:\n>> Felipe Contreras writes:\n>>\n>>>> If you come from \"git pull\" is \"git fetch\" + \"git merge\",\n>>>> and if your current branch is integrating with your local branch,\n>>>\n>>> How many times do I have to say that 'git pull' is not 'git fetch' +\n>>> 'git merge'?\n>>>\n>>> You must think everybody has 'merge.defaulttoupstream=true'.\n>>\n>> I am confused. What does that have anything to do with this topic?\n>> It only affects what a lazy \"git merge\" (without any other parameter\n>> on the command line) does, doesn't it?\n>\n> And that's what we are talking about here; commands without any other\n> parameter in the command like.\n>\n> So \"git pull $nothing\" is *not* \"git fetch $nothing\" + \"git merge $nothing\".\n\nOf course not. But what does it change the equation?\n\nLet's rephrase the above, then.\n\n\t\"git pull\" with 0 or more arguments is to first\n\n - make sure that necessary history is available in your\n repository\n\n - prepare FETCH_HEAD to record what is to be merged\n\n which is done by running \"git fetch\" with appropriate\n arguments against the repository of your upstream, and then\n to\n\n - merge the upstream history\n\n which is done by running \"git merge\" with appropriate\n arguments (which in turn is formulated by reading FETCH_HEAD\n that is left by the previous \"git fetch\" step).\n\nSo if your \"upstream\" happens to live in a local repository, it is\nvery natural to run \"git fetch\" against repository \".\" (with\nappropriate arguments, like 'refs/heads/master' if you were on your\nmywork branch that was forked from your 'master' branch). Running\n\"git fetch .\" is hardly \"does not make any sense whatever\" from that\npoint of view. It is just a natural consequence that our local\nrepository is merely one of the repositories we could fetch/pull\nfrom.\n"},{"id":"217668","messageId":"CAMP44s0J7vcxno=v9_ewUE6FcuRVuYQhCNVS8D+AvP6cG2XNfQ@mail.gmail.com","threadId":"33834","inReplyTo":"7vk3my33vb.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 1/3] fetch: add --allow-local option","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-05-17T00:04:47Z","receivedAt":"2013-05-17T00:04:47Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, May 16, 2013 at 6:24 PM, Junio C Hamano wrote:\n> Felipe Contreras writes:\n>\n>> On Thu, May 16, 2013 at 1:04 PM, Junio C Hamano wrote:\n>>> Felipe Contreras writes:\n>>>\n>>>>> If you come from \"git pull\" is \"git fetch\" + \"git merge\",\n>>>>> and if your current branch is integrating with your local branch,\n>>>>\n>>>> How many times do I have to say that 'git pull' is not 'git fetch' +\n>>>> 'git merge'?\n>>>>\n>>>> You must think everybody has 'merge.defaulttoupstream=true'.\n>>>\n>>> I am confused. What does that have anything to do with this topic?\n>>> It only affects what a lazy \"git merge\" (without any other parameter\n>>> on the command line) does, doesn't it?\n>>\n>> And that's what we are talking about here; commands without any other\n>> parameter in the command like.\n>>\n>> So \"git pull $nothing\" is *not* \"git fetch $nothing\" + \"git merge $nothing\".\n>\n> Of course not. But what does it change the equation?\n>\n> Let's rephrase the above, then.\n>\n> \"git pull\" with 0 or more arguments is to first\n>\n> - make sure that necessary history is available in your\n> repository\n>\n> - prepare FETCH_HEAD to record what is to be merged\n>\n> which is done by running \"git fetch\" with appropriate\n> arguments against the repository of your upstream, and then\n> to\n>\n> - merge the upstream history\n>\n> which is done by running \"git merge\" with appropriate\n> arguments (which in turn is formulated by reading FETCH_HEAD\n> that is left by the previous \"git fetch\" step).\n>\n> So if your \"upstream\" happens to live in a local repository, it is\n> very natural to run \"git fetch\" against repository \".\" (with\n> appropriate arguments, like 'refs/heads/master' if you were on your\n> mywork branch that was forked from your 'master' branch). Running\n> \"git fetch .\" is hardly \"does not make any sense whatever\" from that\n> point of view. It is just a natural consequence that our local\n> repository is merely one of the repositories we could fetch/pull\n> from.\n\nThis is irrelevant, it's an implementation detail of 'git pull'. *THE\nUSER* is not running 'git fetch .' (s)he is running 'git push .'. ONCE\nAGAIN; I'm not talking about 'git pull .' I am talking about 'git\nfetch .' (a *USER*-run 'git fetch .'), and a *USER*-run 'git fetch .'\ndoes *not* make any sense whatsoever.\n\n-- \nFelipe Contreras\n"},{"id":"217752","messageId":"7vtxm1xxvd.fsf@alter.siamese.dyndns.org","threadId":"33834","inReplyTo":"CAMP44s0J7vcxno=v9_ewUE6FcuRVuYQhCNVS8D+AvP6cG2XNfQ@mail.gmail.com","subject":"Re: [PATCH 1/3] fetch: add --allow-local option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-05-17T18:30:30Z","receivedAt":"2013-05-17T18:30:30Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> This is irrelevant, it's an implementation detail of 'git pull'. *THE\n> USER* is not running 'git fetch .'\n\nTo those who fear running \"git pull\", the following has worked as a\nquick way to \"preview\" what they would be getting.\n\n\tgit fetch\n git log ..FETCH_HEAD\n\nand then they can \"git merge FETCH_HEAD\" to conclude it, or run a\n\"git pull\" for real. We teach the more explicit form to end users\nin our tutorial, but it shows the explicit form only because we want\nto illustrate what goes on. Over time we added support to \"git fetch\"\n(and \"git pull\") to make it possible for users to type less when the\nremote and branch involved are obvious, but we carefully avoided\nbreaking this expectation.\n\nSo when \"the user\" is running \"git fetch\" on \"mywork\" branch that\nhappens to be forked from a local \"master\", i.e. her configuration\nis set as\n\n\t[branch \"mywork\"]\n \tremote = .\n merge = refs/heads/master\n\nwe still need to have FETCH_HEAD updated to point at what we would\nbe merging if she did a \"git pull\". It may be OK to additionally\nfetch objects from 'origin' and update the remote tracking branches\nassociated with 'origin', but anything from 'origin' should not\ncontaminate what results in FETCH_HEAD---it should record whatever\nwe record when we did fetch refs/heads/master from '.'.\n\nAs I said in the very beginning, it was a mistake for me to suggest\nadding a special case behaviour for '.' remote in the first place.\nIt breaks a long-standing expectation and workflow built around it.\n\nSo sorry for wasting our time, and consider this as a misguided\nexcursion.\n"},{"id":"217814","messageId":"CAMP44s3xdWzVviPvrN7D1fTG6Lwgg-dEzju--VuiwZA-8bV+MQ@mail.gmail.com","threadId":"33834","inReplyTo":"7vtxm1xxvd.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 1/3] fetch: add --allow-local option","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-05-18T12:25:37Z","receivedAt":"2013-05-18T12:25:37Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Fri, May 17, 2013 at 1:30 PM, Junio C Hamano wrote:\n> Felipe Contreras writes:\n>\n>> This is irrelevant, it's an implementation detail of 'git pull'. *THE\n>> USER* is not running 'git fetch .'\n>\n> To those who fear running \"git pull\", the following has worked as a\n> quick way to \"preview\" what they would be getting.\n>\n> git fetch\n> git log ..FETCH_HEAD\n>\n> and then they can \"git merge FETCH_HEAD\" to conclude it, or run a\n> \"git pull\" for real. We teach the more explicit form to end users\n> in our tutorial,\n\nThat \"tutorial\" is mostly irrelevant; it has not been properly updated\nin years, and it doesn't do it's job properly.\n\nNowadays most people use the Pro Git book, which doesn't mention\nFETCH_HEAD even once. And why would it? It's not a useful concept for\ntypical users.\n\n> So when \"the user\" is running \"git fetch\" on \"mywork\" branch that\n> happens to be forked from a local \"master\", i.e. her configuration\n> is set as\n>\n> [branch \"mywork\"]\n> remote = .\n> merge = refs/heads/master\n>\n> we still need to have FETCH_HEAD updated to point at what we would\n> be merging if she did a \"git pull\".\n\nNo, we don't need that. That is only needed by 'git pull', and in\nfact, it should be possible to reimplement 'git pull' so that it skips\nFETCH_HEAD when the remote is local.\n\nThese are mere implementation details.\n\n> As I said in the very beginning, it was a mistake for me to suggest\n> adding a special case behaviour for '.' remote in the first place.\n> It breaks a long-standing expectation and workflow built around it.\n\nThe fact that it's \"long-standing\" doesn't mean it's sane.\n\n> So sorry for wasting our time, and consider this as a misguided\n> excursion.\n\nIt doesn't matter, the problem that 'git fetch' does something totally\nand completely uses is still there.\n\n-- \nFelipe Contreras\n"},{"id":"217815","messageId":"E74470E4201142788D36127322130401@PhilipOakley","threadId":"33834","inReplyTo":"7vtxm1xxvd.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 1/3] fetch: add --allow-local option","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-05-18T13:12:05Z","receivedAt":"2013-05-18T13:12:05Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Junio C Hamano\" \nSent: Friday, May 17, 2013 7:30 PM\nSubject: Re: [PATCH 1/3] fetch: add --allow-local option\n\n[...]\n\n> So when \"the user\" is running \"git fetch\" on \"mywork\" branch that\n> happens to be forked from a local \"master\", i.e. her configuration\n> is set as\n>\n> [branch \"mywork\"]\n> remote = .\n> merge = refs/heads/master\n>\n\nWas the '.' example illustrative rather than exact. I see no case of \nusing '.' in my configs. Or am I completely missing the point? (e.g. \nthat the use of '.' an example of possible future usage)?\n\n\n> we still need to have FETCH_HEAD updated to point at what we would\n> be merging if she did a \"git pull\". It may be OK to additionally\n> fetch objects from 'origin' and update the remote tracking branches\n> associated with 'origin', but anything from 'origin' should not\n> contaminate what results in FETCH_HEAD---it should record whatever\n> we record when we did fetch refs/heads/master from '.'.\n>\n> As I said in the very beginning, it was a mistake for me to suggest\n> adding a special case behaviour for '.' remote in the first place.\n> It breaks a long-standing expectation and workflow built around it.\n>\n> So sorry for wasting our time, and consider this as a misguided\n> excursion.\n> --\n\nPhilip \n"},{"id":"217816","messageId":"CAMP44s3oNyCzH=ySNuB0f6yn536S=pUKDETAhBOwk_siFn30EQ@mail.gmail.com","threadId":"33834","inReplyTo":"E74470E4201142788D36127322130401@PhilipOakley","subject":"Re: [PATCH 1/3] fetch: add --allow-local option","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-05-18T14:23:35Z","receivedAt":"2013-05-18T14:23:35Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sat, May 18, 2013 at 8:12 AM, Philip Oakley wrote:\n> From: \"Junio C Hamano\" \n> Sent: Friday, May 17, 2013 7:30 PM\n> Subject: Re: [PATCH 1/3] fetch: add --allow-local option\n>\n> [...]\n>\n>\n>> So when \"the user\" is running \"git fetch\" on \"mywork\" branch that\n>> happens to be forked from a local \"master\", i.e. her configuration\n>> is set as\n>>\n>> [branch \"mywork\"]\n>> remote = .\n>> merge = refs/heads/master\n>>\n>\n> Was the '.' example illustrative rather than exact. I see no case of using\n> '.' in my configs. Or am I completely missing the point? (e.g. that the use\n> of '.' an example of possible future usage)?\n\n% git checkout -t -b feature master\n# work\n% git rebase -i\n\n-- \nFelipe Contreras\n"},{"id":"217829","messageId":"2B281B554A864399824A4BCD613A819D@PhilipOakley","threadId":"33834","inReplyTo":"CAMP44s3oNyCzH=ySNuB0f6yn536S=pUKDETAhBOwk_siFn30EQ@mail.gmail.com","subject":"Re: [PATCH 1/3] fetch: add --allow-local option","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-05-18T20:53:56Z","receivedAt":"2013-05-18T20:53:56Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Felipe Contreras\" \nSent: Saturday, May 18, 2013 3:23 PM\n> On Sat, May 18, 2013 at 8:12 AM, Philip Oakley \n> wrote:\n>> From: \"Junio C Hamano\" \n>> Sent: Friday, May 17, 2013 7:30 PM\n>> Subject: Re: [PATCH 1/3] fetch: add --allow-local option\n>>\n>> [...]\n>>\n>>\n>>> So when \"the user\" is running \"git fetch\" on \"mywork\" branch that\n>>> happens to be forked from a local \"master\", i.e. her configuration\n>>> is set as\n>>>\n>>> [branch \"mywork\"]\n>>> remote = .\n>>> merge = refs/heads/master\n>>>\n>>\n>> Was the '.' example illustrative rather than exact. I see no case of\n>> using\n>> '.' in my configs. Or am I completely missing the point? (e.g. that\n>> the use\n>> of '.' an example of possible future usage)?\n>\n> % git checkout -t -b feature master\n> # work\n> % git rebase -i\n>\n> -- \n> Felipe Contreras\n> --\n\nOK, I see it (the dot '.' in the config file) now.\n\nI've also located the documentation hidden at the end of git-config(1)\nunder branch..merge, even though your worked example has it\nunder remote not merge.\n [branch \"feature\"]\n remote = .\n merge = refs/heads/master\n\n\"If you wish to setup git pull so that it merges into from\nanother branch in the local repository, you can point\nbranch..merge to the desired branch, and use the special setting .\n(a period) for branch..remote.\"\n\nIt feels as if this dwimmery(?) should also be listed in the gitcli(7)\ndocumenation and under branch..remote in git-config(1) above it.\n\nThe use of dot '.' occured in a reply a couple of weeks ago:\n\nSent: Saturday, May 04, 2013 7:51 PM\nSubject: Re: Pitfalls in auto-fast-forwarding heads that are not checked \nout?\n\"Jonathan Nieder\" wrote:\n> Another trick is to use \"git push\":\n> git push . $production_sha1:refs/heads/master\n\n\nPhilip\n"},{"id":"217832","messageId":"CAMP44s3kyPdUZXUvG7cR8HMKXvna57t7A_ZAFD5L8mu4M4OfYA@mail.gmail.com","threadId":"33834","inReplyTo":"2B281B554A864399824A4BCD613A819D@PhilipOakley","subject":"Re: [PATCH 1/3] fetch: add --allow-local option","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-05-18T22:26:01Z","receivedAt":"2013-05-18T22:26:01Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sat, May 18, 2013 at 3:53 PM, Philip Oakley wrote:\n> From: \"Felipe Contreras\" \n> Sent: Saturday, May 18, 2013 3:23 PM\n>>\n>> On Sat, May 18, 2013 at 8:12 AM, Philip Oakley \n>> wrote:\n>>>\n>>> From: \"Junio C Hamano\" \n>>> Sent: Friday, May 17, 2013 7:30 PM\n>>> Subject: Re: [PATCH 1/3] fetch: add --allow-local option\n>>>\n>>> [...]\n>>>\n>>>\n>>>> So when \"the user\" is running \"git fetch\" on \"mywork\" branch that\n>>>> happens to be forked from a local \"master\", i.e. her configuration\n>>>> is set as\n>>>>\n>>>> [branch \"mywork\"]\n>>>> remote = .\n>>>> merge = refs/heads/master\n>>>>\n>>>\n>>> Was the '.' example illustrative rather than exact. I see no case of\n>>> using\n>>> '.' in my configs. Or am I completely missing the point? (e.g. that\n>>> the use\n>>> of '.' an example of possible future usage)?\n>>\n>>\n>> % git checkout -t -b feature master\n>> # work\n>> % git rebase -i\n>>\n>> --\n>> Felipe Contreras\n>> --\n>\n>\n> OK, I see it (the dot '.' in the config file) now.\n>\n> I've also located the documentation hidden at the end of git-config(1)\n> under branch..merge, even though your worked example has it\n> under remote not merge.\n> [branch \"feature\"]\n>\n> remote = .\n> merge = refs/heads/master\n>\n> \"If you wish to setup git pull so that it merges into from\n> another branch in the local repository, you can point\n> branch..merge to the desired branch, and use the special setting .\n> (a period) for branch..remote.\"\n\nThis is called the upstream branch. Go to any branch, and do this:\n\n% git checkout feature\n% git branch --set-upstream-to master\n\nAnd it would set:\n\n remote = .\n merge = refs/heads/master\n\nNow you can do things like:\n\n% git log feature@{upstream}..feature\n\nWhich gets translated to:\n\n% git log master..feature\n\nAnd:\n\n% git rebase -i\n\nWhich gets translated to:\n\n% git rebase -i master\n\nThis is nothing new.\n\n-- \nFelipe Contreras\n"},{"id":"217839","messageId":"7vtxlz1pr1.fsf@alter.siamese.dyndns.org","threadId":"33834","inReplyTo":"CAMP44s3xdWzVviPvrN7D1fTG6Lwgg-dEzju--VuiwZA-8bV+MQ@mail.gmail.com","subject":"Re: [PATCH 1/3] fetch: add --allow-local option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-05-19T05:51:30Z","receivedAt":"2013-05-19T05:51:30Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> On Fri, May 17, 2013 at 1:30 PM, Junio C Hamano wrote:\n>> Felipe Contreras writes:\n>>\n>>> This is irrelevant, it's an implementation detail of 'git pull'. *THE\n>>> USER* is not running 'git fetch .'\n>>\n>> To those who fear running \"git pull\", the following has worked as a\n>> quick way to \"preview\" what they would be getting.\n>>\n>> git fetch\n>> git log ..FETCH_HEAD\n>>\n>> and then they can \"git merge FETCH_HEAD\" to conclude it, or run a\n>> \"git pull\" for real. We teach the more explicit form to end users\n>> in our tutorial,\n>\n> That \"tutorial\" is mostly irrelevant; it has not been properly updated\n> in years, and it doesn't do it's job properly.\n>\n> Nowadays most people use the Pro Git book, which doesn't mention\n> FETCH_HEAD even once. And why would it?\n\nBecause the book was written by those who did not know about its\nuse, and I do not necessarily think it is their fault. Our own\ndocumentation can use updates.\n\nPatches to the tutorial to explain (you can refer to postings by\npeople who discuss on public \"users help other users\" site like\nstackoverflow) the equivalence of the \"git pull\" == \"git fetch\"\nfollowed by \"git merge FETCH_HEAD\" better than it currently does is\nwelcome. IIUC, ProGit is maintained in public and you can send\npatches to it, too.\n\nUsers of stackoverflow seem to know about and how to use FETCH_HEAD:\n\n http://stackoverflow.com/questions/9237348/what-does-fetch-head-in-git-mean\n http://stackoverflow.com/questions/11478558/fetch-head-not-updating-after-git-fetch\n\nand they expect exactly what I described in the earlier message. If\nyou ask your search engine about \"FETCH_HEAD\", you would find other\nreal-world use of it as well (one of them I found was about somebody\nrequesting to teach TortoiseGit to offer FETCH_HEAD as a candate to\nbe merged, IIRC).\n\nIncidentally, this discussion on our own list\n\n http://thread.gmane.org/gmane.comp.version-control.git/42788/focus=42798\n\nshows that I was originally not very keen to defend \"fetch, then\ninspect with log FETCH_HEAD, and then finally merge\" workflow to\nkeep working myself [*1*], which is somewhat funny.\n\nSo, no, it is not my whim, but people do depend on \"git fetch\" that\nupdates FETCH_HEAD to what is to be merged with \"git pull\".\n\n>> So when \"the user\" is running \"git fetch\" on \"mywork\" branch that\n>> happens to be forked from a local \"master\",...\n>> we still need to have FETCH_HEAD updated to point at what we would\n>> be merging if she did a \"git pull\".\n>\n> No, we don't need that. That is only needed by 'git pull', and in\n> fact, it should be possible to reimplement 'git pull' so that it skips\n> FETCH_HEAD when the remote is local.\n>\n> These are mere implementation details.\n\nYou seem to be incapable to understand what backward compatibility\nis. It is not about \"keep only what I use myself, I think others\nshould use, and/or I understand, working, and destroy everything\nelse\".\n\nAlso your \"special-case local repository and fetch from 'origin'\"\nbreaks down once your users need to work on a project with subsystem\nmaintainers.\n\nImagine one clones from me (i.e. git.git is her upstream), and forks\nher fh-octopus branch out of her master branch (\"git clone\" arranges\nthe latter to be a fork of origin/master taken from me). She helps\ngit-svn and has Eric's repository as her \"git-svn\" remote (because\nmy tree lags behind Eric's tree with respect to git-svn). Her local\ngit-svn branch is a fork of Eric's master, and she has her svn-ext\nbranch that is a fork of it [*2*].\n\n git clone git://git.kernel.org/pub/scm/git/git.git git\n cd git\n\n git checkout -t -b fh-octopus master\n git remote add git-svn git://git.bogomips.org/git-svn.git/\n git checkout -t -b git-svn git-svn/master\n git checkout -t -b svn-ext git-svn\n\nShe has four local branches, master, fh-octopus, git-svn, and\nsvn-ext. Is this a too-contrived example? I do not think so.\n\nOn any of these branches, she can say\n\n git pull [--rebase]\n\nwithout having to be constantly aware of what branch (either remote\nor local) the work on her current branch builds on. Like some\npeople in the thread $gmane/42788 discussion, she may prefer to do\nthe same integration with \"first fetch, inspect and then integrate\"\nworkflow, relying on the equivalence \"git pull\" == \"git fetch\" +\n\"git merge/rebase\":\n\n git fetch\n git log ..FETCH_HEAD\n git merge FETCH_HEAD\n\nBut when she does this:\n\n git checkout fh-octopus\n git fetch\n\nthe \"git fetch\" does not fetch from me (i.e. her 'origin').\n\nWould she be unhappy?\n\nI agree that it could be argued so.\n\nAfter all, she is working on a topic that is eventually based on my\n'master' and the only reason she forked from her 'master' is because\nshe may have other changes of her own on her 'master' that are not\nnecessarily related to her fh-octopus topic. She wants her \"git log\n@{u}..\" not to show those unrelated changes on her 'master', but\nwants to rebase against her 'master'.\n\nBecause her @{u} does not refer to 'origin/master' taken from me (it\nrefers to her local 'master'), however, even if we change \"git\nfetch\" to fetch from 'origin', what \"git log ..@{u}\" shows does not\nchange, so the only \"improvement\" is that it does not trigger \"I\nsaid 'git fetch' but it did not fetch anything? Did I make some\nmistake?\" confusion.\n\nIs that lack of confusion a big enough improvement, or is it easy\nenough for her to realize that what she wanted to inspect was what\nI've been doing in the meantime and run \"git fetch origin\"?\n\nI know you would say it is an improvement; I am on the fence in the\nsense that no confusion is better than confusion, but that is a\nqualified \"on the fence\". I do not mind it fixed as long as the\nconfusion avoidance does not regress other aspects of the operation\nwe have kept working for people.\n\nBut more importantly, what should happen when she is working on her\nsvn-ext branch?\n\n git checkout svn-ext\n git fetch\n\nThis does not fetch from me (i.e. her 'origin'), either. If this\nfetched from me, would she be happier?\n\nIt could be argued that it might be better if it fetched from Eric;\nafter all she is working on svn-ext that eventually reaches Eric's\ntree. But fetching from me while she is working on svn-ext does not\nmake any sense at all in her set-up, does it?\n\nAs I already said, I am OK with an enhancement that does (an\nequivalent of) the following:\n\n - Teach \"git fetch --no-fetch-head \" an option that\n causes it to do everything \"git fetch \" would do,\n except that in that mode, it does not touch FETCH_HEAD at all\n (the \"--append\" option that changes the behaviour of \"git fetch\"\n to only change what happens to FETCH_HEAD can be thought of a\n precedent).\n\n - Only when 'git fetch' (with no parameters, i.e. relies on\n configured defaults) is to fetch from '.':\n\n - First internally fork and run \"git fetch --no-fetch-head\n \" from the found by the following loop:\n\n - Set a variable B to the name of the current branch \n - while branch.B.remote is the local repository:\n - assign the branch the branch B forked from,\n i.e. branch.B.merge, to variable B\n - branch.B.remote is the first remote repository in the fork\n ancestry chain. That is the we are looking for.\n\n - Then do the usual 'git fetch' against the local repository,\n leaving what is to be merged in FETCH_HEAD as usual.\n\n - (optional) make the second \"special case\" opt-in, as people who\n have known Git may be upset when their \"git pull\" that they know\n would go to local repository touches network. I do not think it\n is a huge deal, though, and that is why I marked it as optional.\n\nI think that would alleviate the puzzlement some people may feel\nwhen they run 'git fetch' on a branch that integrates with their\nlocal branch, and sees no objects are transferred. It would do so\nwithout breaking anything.\n\nAnything that breaks the \"pull=fetch+merge\" equivalence is not\nacceptable and no loud repeating from you will change that, with or\nwithout patches.\n\nWe owe at least that much to the people who asked us to keep it\nworking over time and those who responded to them by working on\nmaintaining it over time.\n\n\n[Footnotes]\n\n*1* Back then, FETCH_HEAD did not have the commit to be merged\n necessarily on the first line, so it was not very easy to work\n with it. But that was fixed by 96890f4c428e (write first\n for-merge ref to FETCH_HEAD first, 2011-12-26), has been with us\n since v1.7.9, and the fix was not made by me, but Joey Hess.\n\n\n*2* The invariant \"git pull \" == \"git fetch \" + \"git merge FETCH_HEAD\" (for any ,\n including empty) has been true forever, and over time we made\n sure it hold true when we introduced new features because people\n depended on it, with commmits like these:\n\n - 85295a52e683 (git-merge: Put FETCH_HEAD data in merge commit\n message, 2007-03-22)\n\n - 96890f4c428e (write first for-merge ref to FETCH_HEAD first,\n 2011-12-26)\n\n A remaining known bug is when the pull is to create an octopus,\n because \"git merge FETCH_HEAD\" currently can resolve FETCH_HEAD\n as only one commit. The fh-octopus topic would extend the itch\n these two fixes started to scratch by teaching \"git merge\" to\n expand FETCH_HEAD into all commits that are not marked as\n not-for-merge to finish scratching that itch.\n\n svn-ext may teach git-svn to express a svn external as a git\n submodule.\n"},{"id":"217841","messageId":"7vip2f1ovd.fsf@alter.siamese.dyndns.org","threadId":"33834","inReplyTo":"E74470E4201142788D36127322130401@PhilipOakley","subject":"Re: [PATCH 1/3] fetch: add --allow-local option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-05-19T06:10:30Z","receivedAt":"2013-05-19T06:10:30Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Philip Oakley\" writes:\n\n> From: \"Junio C Hamano\" \n> Sent: Friday, May 17, 2013 7:30 PM\n> Subject: Re: [PATCH 1/3] fetch: add --allow-local option\n>\n> [...]\n>\n>> So when \"the user\" is running \"git fetch\" on \"mywork\" branch that\n>> happens to be forked from a local \"master\", i.e. her configuration\n>> is set as\n>>\n>> [branch \"mywork\"]\n>> remote = .\n>> merge = refs/heads/master\n>>\n>\n> Was the '.' example illustrative rather than exact. \n\nIt is exactly spelled like so. Just like '.' in the filesystem\nrefers to our current directory, a dot-repository used there refers\nto our local repository. \"Git is distributed and no repository is\nspecial\" principle extends to our own local repository in that you\ncan use it just like you can use anybody else's repository as the\nsource of fetch or the destination of push.\n"},{"id":"217850","messageId":"51986cef178dc_7301727e1442892@nysa.mail","threadId":"33834","inReplyTo":"7vtxlz1pr1.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 1/3] fetch: add --allow-local option","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-05-19T06:10:55Z","receivedAt":"2013-05-19T06:10:55Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Felipe Contreras writes:\n> \n> > On Fri, May 17, 2013 at 1:30 PM, Junio C Hamano wrote:\n> >> Felipe Contreras writes:\n> >>\n> >>> This is irrelevant, it's an implementation detail of 'git pull'. *THE\n> >>> USER* is not running 'git fetch .'\n> >>\n> >> To those who fear running \"git pull\", the following has worked as a\n> >> quick way to \"preview\" what they would be getting.\n> >>\n> >> git fetch\n> >> git log ..FETCH_HEAD\n> >>\n> >> and then they can \"git merge FETCH_HEAD\" to conclude it, or run a\n> >> \"git pull\" for real. We teach the more explicit form to end users\n> >> in our tutorial,\n> >\n> > That \"tutorial\" is mostly irrelevant; it has not been properly updated\n> > in years, and it doesn't do it's job properly.\n> >\n> > Nowadays most people use the Pro Git book, which doesn't mention\n> > FETCH_HEAD even once. And why would it?\n> \n> Because the book was written by those who did not know about its\n> use, and I do not necessarily think it is their fault.\n\nThat's an _assumption_, and I don't think it's correct; the authors might very\nwell know about FETCH_HEAD, but made a conscious decision to avoid explaining\nsuch low-level concepts to people trying to learn Git; they are irrelevant to\nthem. I'm sure they skipped pack formats, remote-helper interfaces, and a lot\nof other implementation details users don't need to know about.\n\nFETCH_HEAD is simply another implementation detail users don't need to\nknow, so it doesn't belong in Pro Git, a book designed for people trying\nto learn Git.\n\n> Our own documentation can use updates.\n\nYeah, sure. I've tried to fix the tutorial, it's not an experience I would\nwish to anybody, especially not people unfamiliar with Git, who are the\npeople better suited to understand what is confusing about Git.\n\nIOW, the documentation is destined to oblivion, because the only people\nthat could point out the inconsistencies and irrelevancies, are\nprecisely the people that don't contribute to Git. And the people who do\ncontribute to Git, and have enough empathy to put themselves in the\nshoes of users, are shun for 'rocking the boat'.\n\nYes, the documentation *can* use updates, but won't.\n\n> IIUC, ProGit is maintained in public and you can send patches to it,\n> too.\n\nYes, and I will send patches, but about issues that *matter*. Why would\nI send a patch to add text about a feature *nobody* needs to know?\n\n> Users of stackoverflow seem to know about and how to use FETCH_HEAD:\n> \n> http://stackoverflow.com/questions/9237348/what-does-fetch-head-in-git-mean\n> http://stackoverflow.com/questions/11478558/fetch-head-not-updating-after-git-fetch\n\nThis is a cheeky use of rhetoric, it implies that *all* users of\nstackoverflow know about this, and it's not true.\n\nCounting the amount of votes, the best we can say is at most 20 people\n'know' about this. A more specific description of the situation would be\nthat at most 20 people _knew_ about this, at the time they read it; they\nmight have forgotten already. But more importantly, only 14 people voted\nfor this question, and only 7 people starred it.\n\nThe top question 'How do I edit an incorrect commit message in Git?'\nabout Git has 2871 votes and 822 stars, which is more than 200 times.\nCan we say that stackoverflows \"know\" how to amend a commit? Well, if\nthey knew why it continues to receive votes?\n\nSo if one question has 2871 votes, and the other one has 14 votes, does\nit mean they 'know' one question, and not the other one? At which point\ndo the users stop 'knowing' the answer to the question? If a question is\nposted, does it mean that automatically stackoverflow users 'know' about\nit?\n\nNo, we don't known what stackoverflow users seem to \"know\", we can only\nknow what *some* of them consider a good question, and a good answer.\nThat's all.\n\n> and they expect exactly what I described in the earlier message.\n\nWrong. From those links only one person expected this to happen, and he\nreceived zero votes, which can be translated to; nobody cares.\n\n> If you ask your search engine about \"FETCH_HEAD\", you would find other\n> real-world use of it as well (one of them I found was about somebody\n> requesting to teach TortoiseGit to offer FETCH_HEAD as a candate to be\n> merged, IIRC).\n\nI'm sure there are people out there that would find uses for FETCH_HEAD,\nyou can probably count them with the fingers in your hand, even if half\nof them were missing.\n\nThis patch would do *nothing* to harm those suers, because they can\nstill do 'git fetch .', or even 'git fetch --allow-local'. The two\npersons in the world that do expect 'git fetch' without arguments to\nupdate FETCH_HEAD, will have to specify another single character\nargument. Big whooping do.\n\nThe rest of the results in Google show basically only bugs, and patches.\n\nEven if all those results were about interesting things people do with\nFETCH_HEAD, that has absolutely nothing to do with the issue at hand,\nwhich is 'git fetch' without arguments.\n\nThis is just a red herring.\n\n> Incidentally, this discussion on our own list\n> \n> http://thread.gmane.org/gmane.comp.version-control.git/42788/focus=42798\n\nThis explicitly says 'git fetch ', it has nothing to do with 'git\nfetch' without arguments.\n\nMoreover, it explicitly says:\n\n> I often like to fetch some code from others, review and then merge.\n\n'git fetch .' does not help one iota to this use-case.\n\n> shows that I was originally not very keen to defend \"fetch, then\n> inspect with log FETCH_HEAD, and then finally merge\" workflow to\n> keep working myself [*1*], which is somewhat funny.\n> \n> So, no, it is not my whim, but people do depend on \"git fetch\" that\n> updates FETCH_HEAD to what is to be merged with \"git pull\".\n\nThey depend on that when they merge a *REMOTE*; a remote remote, not a\nlocal remote ('.').\n\nThere's *absolutely* no reason why anybody would ever rely on 'git fetch\n.' followed by 'git merge FETCH_HEAD'.\n\n> >> So when \"the user\" is running \"git fetch\" on \"mywork\" branch that\n> >> happens to be forked from a local \"master\",...\n> >> we still need to have FETCH_HEAD updated to point at what we would\n> >> be merging if she did a \"git pull\".\n> >\n> > No, we don't need that. That is only needed by 'git pull', and in\n> > fact, it should be possible to reimplement 'git pull' so that it skips\n> > FETCH_HEAD when the remote is local.\n> >\n> > These are mere implementation details.\n> \n> You seem to be incapable to understand what backward compatibility\n> is.\n\nI'll explain why that is wrong in so many levels in a separate mail.\n\n> It is not about \"keep only what I use myself, I think others\n> should use, and/or I understand, working, and destroy everything\n> else\".\n\nThis is just bullshit. Nobody is destroying anything. The users can just\ndo 'git fetch .' and be done with it, but of course they won't, because\nthat doesn't do anything useful.\n\n> Also your \"special-case local repository and fetch from 'origin'\"\n> breaks down once your users need to work on a project with subsystem\n> maintainers.\n\nIf 'git fetch' -> 'git fetch origin' is broken, then we are already\nbroken, because that's what happens by default.\n\n> Imagine one clones from me (i.e. git.git is her upstream), and forks\n> her fh-octopus branch out of her master branch (\"git clone\" arranges\n> the latter to be a fork of origin/master taken from me). She helps\n> git-svn and has Eric's repository as her \"git-svn\" remote (because\n> my tree lags behind Eric's tree with respect to git-svn). Her local\n> git-svn branch is a fork of Eric's master, and she has her svn-ext\n> branch that is a fork of it [*2*].\n> \n> git clone git://git.kernel.org/pub/scm/git/git.git git\n> cd git\n> \n> git checkout -t -b fh-octopus master\n> git remote add git-svn git://git.bogomips.org/git-svn.git/\n> git checkout -t -b git-svn git-svn/master\n> git checkout -t -b svn-ext git-svn\n> \n> She has four local branches, master, fh-octopus, git-svn, and\n> svn-ext. Is this a too-contrived example? I do not think so.\n> \n> On any of these branches, she can say\n> \n> git pull [--rebase]\n> \n> without having to be constantly aware of what branch (either remote\n> or local) the work on her current branch builds on. Like some\n> people in the thread $gmane/42788 discussion, she may prefer to do\n> the same integration with \"first fetch, inspect and then integrate\"\n> workflow, relying on the equivalence \"git pull\" == \"git fetch\" +\n> \"git merge/rebase\":\n> \n> git fetch\n> git log ..FETCH_HEAD\n> git merge FETCH_HEAD\n> \n> But when she does this:\n> \n> git checkout fh-octopus\n> git fetch\n> \n> the \"git fetch\" does not fetch from me (i.e. her 'origin').\n> \n> Would she be unhappy?\n> \n> I agree that it could be argued so.\n> \n> After all, she is working on a topic that is eventually based on my\n> 'master' and the only reason she forked from her 'master' is because\n> she may have other changes of her own on her 'master' that are not\n> necessarily related to her fh-octopus topic. She wants her \"git log\n> @{u}..\" not to show those unrelated changes on her 'master', but\n> wants to rebase against her 'master'.\n> \n> Because her @{u} does not refer to 'origin/master' taken from me (it\n> refers to her local 'master'), however, even if we change \"git\n> fetch\" to fetch from 'origin', what \"git log ..@{u}\" shows does not\n> change, so the only \"improvement\" is that it does not trigger \"I\n> said 'git fetch' but it did not fetch anything? Did I make some\n> mistake?\" confusion.\n\nThat's correct, but the issue is there no matter what, the only question\nis which of the two options we want:\n\na)\n\n\t% git checkout svn-ext\n\t% git fetch\n\tFrom .\n\t * branch master -> FETCH_HEAD\n\t# oops\n\t% git fetch git-svn\n\t% git log ..FETCH_HEAD\n\t% git merge FETCH_HEAD\n\nb)\n\n\t% git checkout svn-ext\n\t% git fetch\n\tFrom git://git.kernel.org/pub/scm/git/git\n\t 680ed3e..de3a5c6 master -> origin/master\n\t# oops\n\t% git fetch svn-ext\n\t% git log ..FETCH_HEAD\n\t% git merge FETCH_HEAD\n\nFor me a) is totally confusing, maybe this particular user is familiar\nwith FETCH_HEAD, but for the vast majority of other users it's totally\nconfusing. b) is also wrong, but at least it's doing something useful\nand familiar; fetching from a remote remote.\n\nWhy do you ignore b)? Why do you automatically assume a) is best?\n\nYou are jumping to conclusions here.\n\n> As I already said, I am OK with an enhancement that does (an\n> equivalent of) the following:\n> \n> - Teach \"git fetch --no-fetch-head \" an option that\n> causes it to do everything \"git fetch \" would do,\n> except that in that mode, it does not touch FETCH_HEAD at all\n> (the \"--append\" option that changes the behaviour of \"git fetch\"\n> to only change what happens to FETCH_HEAD can be thought of a\n> precedent).\n> \n> - Only when 'git fetch' (with no parameters, i.e. relies on\n> configured defaults) is to fetch from '.':\n> \n> - First internally fork and run \"git fetch --no-fetch-head\n> \" from the found by the following loop:\n> \n> - Set a variable B to the name of the current branch \n> - while branch.B.remote is the local repository:\n> - assign the branch the branch B forked from,\n> i.e. branch.B.merge, to variable B\n> - branch.B.remote is the first remote repository in the fork\n> ancestry chain. That is the we are looking for.\n\nWhy do we need to fork? All we need is go through the 'branch.X.*'\nconfigurations until we find a non-local remote.\n\n> - Then do the usual 'git fetch' against the local repository,\n> leaving what is to be merged in FETCH_HEAD as usual.\n> \n> - (optional) make the second \"special case\" opt-in, as people who\n> have known Git may be upset when their \"git pull\" that they know\n> would go to local repository touches network. I do not think it\n> is a huge deal, though, and that is why I marked it as optional.\n> \n> I think that would alleviate the puzzlement some people may feel\n> when they run 'git fetch' on a branch that integrates with their\n> local branch, and sees no objects are transferred. It would do so\n> without breaking anything.\n> \n> Anything that breaks the \"pull=fetch+merge\" equivalence is not\n> acceptable and no loud repeating from you will change that, with or\n> without patches.\n\nYou are jumping ahead; you go from \"Jane uses FETCH_HEAD\", to \"Jane\nexpects 'git fetch' to do 'git fetch .'\", which is demonstrably false.\n\nYou merely explained why some user might want to use FETCH_HEAD in some\nsituations, which is totally orthogonal to the issue at hand.\n\nThe issue at hand is that 'git fetch' -> 'git fetch .' is useless.\n\nYou are using verbose rhetoric to deflect the issue at hand, and go to\ngreat lengths to explain something that is totally irrelevant, and at no\npoint in time do you touch the issue of a) vs. b).\n\n> We owe at least that much to the people who asked us to keep it\n> working over time and those who responded to them by working on\n> maintaining it over time.\n\nGeezus! This patch doesn't break anything for them. Period.\n\nShow me *one* real use-case this patch breaks. Go on.\n\n-- \nFelipe Contreras\n"},{"id":"217851","messageId":"519885a591924_7301727e144294f@nysa.mail","threadId":"33834","inReplyTo":"7vtxlz1pr1.fsf@alter.siamese.dyndns.org","subject":"About overzealous compatibility","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-05-19T07:56:21Z","receivedAt":"2013-05-19T07:56:21Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Felipe Contreras writes:\n> > On Fri, May 17, 2013 at 1:30 PM, Junio C Hamano wrote:\n\n> >> So when \"the user\" is running \"git fetch\" on \"mywork\" branch that\n> >> happens to be forked from a local \"master\",...\n> >> we still need to have FETCH_HEAD updated to point at what we would\n> >> be merging if she did a \"git pull\".\n> >\n> > No, we don't need that. That is only needed by 'git pull', and in\n> > fact, it should be possible to reimplement 'git pull' so that it skips\n> > FETCH_HEAD when the remote is local.\n> >\n> > These are mere implementation details.\n> \n> You seem to be incapable to understand what backward compatibility\n> is.\n\nReally? Do you even remember the time when you changed out of nowhere\nall the 'git-foo' commands with 'git foo' and all hell broke loose?\n\nI remember some lonely voice of reason shouting for clear deprecation\nwarnings:\n\nhttp://article.gmane.org/gmane.comp.version-control.git/94262\n\nYou seem to not understand what is the purpose of backwards\ncompatibility, so let me explain. The most important aspect of a project\nis not the technical details, or the performance, but it's *usefulness*\nto the users; once a user has decided to use the software, he expects it\nto keep working for his use-cases in the foreseeable future. If something\nchanges, and the user was relying on that, the user would get annoyed,\nbut most likely would not stop using the software. If this happens time\nand again, he might.\n\nIn order to keep as many users as possible, and ensure the project keeps\ngrowing with as strong user and developer base, the old behaviors should\nremain in place as much as possible. This keeps old users happy, and\nallows the project to achieve it's goal; to be useful to many people as\npossible.\n\nThe safest way to never break old behaviors is to never make any change,\nbut this is not ideal, no software is perfect, and the software needs to\nbe constantly evolving, otherwise users will stop using the software as\nwell.\n\nMoving forward while not breaking old behaviors is often times\ndifficult, but necessary, to keep the old users, and the steady growth.\n\nMany projects make the mistake of simply disregarding old users, and\nbreaking things constantly; and while doing so, they keep loosing users,\nand never grow as much as they could. *Nobody* is suggesting Git should\ndo that.\n\nIt's inevitable that there would come a point in time where there would\nbe a conflict of interests, and in order to move forward it's necessary\nto break old behaviors. When such situation arises, it's important to\nexhaust any other options that might allow both the old and new\nbehaviors (like a configuration option), or different implementations. But\nit might be, that there are no alternatives, and either the project\ndoesn't move forward, or compatibility is retained.\n\nWhen analyzing such cases, it's important to understand the impact it\nhas, and how many users it affects; if it's a small change to the user\nwork-flow, but it affects too many users, it might be best to don't go\nforward with the change, or only do so after a major version release,\nwith good communication to minimize the damage. And if it's a big\nchange, but it affects a small user base, it still might make sense to\ngo ahead with the change.\n\nMany times it won't be possible to know how many users would be affects,\nand in those cases it might make sense to release, with a hand in the\nbreaks, so, if a lot of users complain, the change is reverted, and\nnobody, or very few, complain, leave it there. The Linux project does\nthis; revert when somebody shouts.\n\nIn conclusion; you shouldn't blindly dogmatically avoid changes for the\nsake of it; you have to understand *why* you _try_ to retain backwards\ncompatibility, and when it best serves the project not to do so.\n\nIf you try to be too overzealous in your backwards compatibility, you\nrun the risk of not moving fast enough in order to not annoy a handful\nof users, or even imaginary ones who don't even exist. This is not good\nfor the project.\n\nA few days ago somebody used a very appropriate name for it:\ncompabeaten[1]. We want to keep our users happy, but we also want to\nkeep our developers happy, and not being able to move forward with as\nmany features as one would want to is very annoying.\n\nIn the worst case scenario, we can revert a change that many users are\ncomplaining about, we are not GNOME.\n\n[1] http://article.gmane.org/gmane.comp.version-control.git/224510\n\n-- \nFelipe Contreras\n"},{"id":"217909","messageId":"CAMP44s0egmU8jd2+JS3WVcW6R+CMWxbRpSKDaJ5fs7S8Fj+v=A@mail.gmail.com","threadId":"33834","inReplyTo":"519885a591924_7301727e144294f@nysa.mail","subject":"Re: About overzealous compatibility","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-05-19T14:27:38Z","receivedAt":"2013-05-19T14:27:38Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sun, May 19, 2013 at 2:56 AM, Felipe Contreras\n wrote:\n> Junio C Hamano wrote:\n>> Felipe Contreras writes:\n>> > On Fri, May 17, 2013 at 1:30 PM, Junio C Hamano wrote:\n>\n>> >> So when \"the user\" is running \"git fetch\" on \"mywork\" branch that\n>> >> happens to be forked from a local \"master\",...\n>> >> we still need to have FETCH_HEAD updated to point at what we would\n>> >> be merging if she did a \"git pull\".\n>> >\n>> > No, we don't need that. That is only needed by 'git pull', and in\n>> > fact, it should be possible to reimplement 'git pull' so that it skips\n>> > FETCH_HEAD when the remote is local.\n>> >\n>> > These are mere implementation details.\n>>\n>> You seem to be incapable to understand what backward compatibility\n>> is.\n>\n> Really? Do you even remember the time when you changed out of nowhere\n> all the 'git-foo' commands with 'git foo' and all hell broke loose?\n>\n> I remember some lonely voice of reason shouting for clear deprecation\n> warnings:\n>\n> http://article.gmane.org/gmane.comp.version-control.git/94262\n\nAfter re-reading this old thread, I noticed that you didn't get a\nstraight answer, nor was there a neat conclusion, and the good replies\nmight have been lost in the noise. So this is what you should have\ndone:\n\n1) Fix all the tests and documentation to use the 'git foo' form, so\neverything is consistent and the proper form of the commands is\nexplained.\n2) Release v1.6.0 turning on annoying deprecation warnings telling\npeople to stop using 'git-foo'. This wouldn't have had the same bad\neffect that v1.6.0 had, because you added at the same time a\nconfiguration to turn the annoying message off, so users, and\nadministrators can choose to ignore the warning, and then they\ncouldn't complain when the 'git-foo' links get removed for real.\n3) To be absolutely sure that people get the message that there's a\nbig change, name the release v2.0.\n\nI think 3) would have been overkill; v1.7.0 would be OK, but 2) was\ndefinitely needed, and 1) would have been great.\n\nI think it's extremely cheap that you accuse me of not understanding\nbackwards compatibility, when I did for zsh's completion[1] exactly\nwhat you should have done for v1.6.0: add an annoying deprecation\nwarning.\n\nCheers.\n\n[1] http://article.gmane.org/gmane.comp.version-control.git/210024\n\n-- \nFelipe Contreras\n"}]}