{"thread":{"id":"33861","subject":"[PATCH] fetch: add new fetch.default configuration","startedAt":"2013-05-18T02:18:56Z","lastAt":"2013-06-01T14:04:09Z","messageCount":9,"participants":["Felipe Contreras","Ramkumar Ramachandra","Eric Sunshine"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"217775","messageId":"1368843536-19781-1-git-send-email-felipe.contreras@gmail.com","threadId":"33861","inReplyTo":null,"subject":"[PATCH] fetch: add new fetch.default configuration","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-05-18T02:18:56Z","receivedAt":"2013-05-18T02:18:56Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"When the user has an upstream branch configured to track a remote\ntracking branch:\n\n % git checkout --set-upstream-to github/master\n\nDoing a 'git fetch' without any arguments would try to fetch 'github',\nbecause it's configured as current branch's remote\n(branch..remote).\n\nHowever, if we do something slightly different:\n\n % git checkout --set-upstream-to master\n\nDoing a 'git fetch' without any arguments would try to fetch the remote\n'.', for the same reason.\n\nBut, unlike the in the first instance, the second command would not\nupdate any remote tracking branch, in fact, it would not update any\nbranch at all. The only effect is that it would update FETCH_HEAD.\n\nFETCH_HEAD is a special symbol that is used to store the result of a\nfetch. It can be used by other commands of git, specially 'git merge'.\n\nIt is however, barely mentioned in the documentation, and can be\nconsidered a plumbing concept at best, that few Git users would benefit\nfrom using, and indeed, quite likely very few use it, or are even aware\nof it.\n\nSo when the user is presented with a message like this:\n\n % git fetch\n From .\n * branch master -> FETCH_HEAD\n\nThe vast majority of them would have absolutely no idea what's going on.\nMany of them would probably just shrug, and manually specify the remote\nthe want to fetch from, which is 'origin' in many cases.\n\nIf the user has say, twenty branches, ten with a local upstream\n(branch..remote = '.'), and ten without an upstream. The user\nmight get used to typing 'git fetch' and expect Git to fetch from\n'origin' which would happen 50% of the time, but the other 50%, the user\nwould be forced to specify the remote.\n\nThis inconsistency would be simply one more to join the list of\nincomprehensible quirks the user has to put up when using Git, so quite\nlikely (s)he simply gets used to it, only to complain later in forums or\nsocial media, outside of the dwelling distance of the typical Git\ndeveloper.\n\nBut we can do better.\n\nWe can add a new 'fetch.default' configuration variable (one more to\njoin the many necessary to force Git to behave in sane manner), so the\nuser can specify what (s)he wants to be performed when the remote is not\nspecified in the 'git fetch' command.\n\nThis configuration would probably be welcome by 99% of the user\npopulation, who have no clue what FETCH_HEAD is, and do set local\nupstream branches, only to find out weird inconsistent behavior\ndepending on which branch the happen to be sitting at.\n\nWe add documentation and testing as expected, and also introduce other\nchanges necessary to make the configuration enter into effect when it's\nneeded.\n\nThe default (FETCH_DEFAULT_UNSPECIFIED), allows the current behavior to\nbe unmodified, so remote_get(NULL) is called, and the current rules to\ndetermine the default branch remain.\n\nThe new option \"simple\" allows Git to always fetch from \"origin\", which\nis what most users would expect, and it's 100% consistent.\n\nAlternatively, the user can manually specify the current behavior with\n\"current\" (alluding to the current branch), so that the behavior changes\ndepending on which branch the user happens to be sitting at. This would\nallow the user to retain this behavior, if (s)he so wishes,\nin case Git developers regain their sense and set a default that most\nusers would appreciate (\"simple\").\n\nIf the user wants, for whatever strange reason swimming in his/her head,\n(s) can still fetch from a local ('.') remote (even stating that as an\nEnglish sentence doesn't make any sense).\n\n % git fetch .\n From .\n * branch master -> FETCH_HEAD\n\nAnd to any number of weird hacks with FETCH_HEAD.\n\nThe average user lucky enough to find the 'fetch.default' configuration,\nhowever, would never have to enter the word of \"local remote\"\nstrangeness, and would remain comfortably in the place where locals are\nlocals, and remotes are remotes, and 'git fetch' is always consistent,\nand always does something useful.\n\nSigned-off-by: Felipe Contreras \n---\n Documentation/config.txt | 9 +++++++++\n Documentation/git-fetch.txt | 4 ++++\n builtin/fetch.c | 10 +++++++++-\n cache.h | 7 +++++++\n config.c | 21 +++++++++++++++++++++\n environment.c | 1 +\n t/t5513-fetch-track.sh | 43 +++++++++++++++++++++++++++++++++++++++++++\n 7 files changed, 94 insertions(+), 1 deletion(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 6e53fc5..0c48490 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -1860,6 +1860,15 @@ branches are not yet ready to be pushed out. If you are working with\n other people to push into the same shared repository, you would want\n to use one of these.\n \n+fetch.default::\n+\tDefines the action `git fetch` should take if no remote is specified\n+\ton the command line. Possible values are:\n++\n+--\n+* `current` - fetch from the upstream of the current branch.\n+* `simple` - always fetch from `origin`.\n+--\n+\n rebase.stat::\n \tWhether to show a diffstat of what changed upstream since the last\n \trebase. False by default.\ndiff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt\nindex e08a028..5c4afdc 100644\n--- a/Documentation/git-fetch.txt\n+++ b/Documentation/git-fetch.txt\n@@ -37,6 +37,10 @@ or from several repositories at once if is given and\n there is a remotes. entry in the configuration file.\n (See linkgit:git-config[1]).\n \n+When no remote is specified, by the default the `origin` remote will be used,\n+unless there's an upstream branch configured for the current branch. This can\n+be configured with `fetch.default`.\n+\n OPTIONS\n -------\n include::fetch-options.txt[]\ndiff --git a/builtin/fetch.c b/builtin/fetch.c\nindex 4b6b1df..8e1a79d 100644\n--- a/builtin/fetch.c\n+++ b/builtin/fetch.c\n@@ -973,6 +973,7 @@ int cmd_fetch(int argc, const char **argv, const char *prefix)\n \tfor (i = 1; i < argc; i++)\n \t\tstrbuf_addf(&default_rla, \" %s\", argv[i]);\n \n+\tgit_config(git_default_config, NULL);\n \targc = parse_options(argc, argv, prefix,\n \t\t\t builtin_fetch_options, builtin_fetch_usage, 0);\n \n@@ -1006,7 +1007,14 @@ 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\tswitch (fetch_default) {\n+\t\tcase FETCH_DEFAULT_SIMPLE:\n+\t\t\tremote = remote_get(\"origin\");\n+\t\t\tbreak;\n+\t\tdefault:\n+\t\t\tremote = remote_get(NULL);\n+\t\t\tbreak;\n+\t\t}\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/cache.h b/cache.h\nindex 7ce9061..bb646bb 100644\n--- a/cache.h\n+++ b/cache.h\n@@ -603,9 +603,16 @@ enum push_default_type {\n \tPUSH_DEFAULT_UNSPECIFIED\n };\n \n+enum fetch_default_type {\n+\tFETCH_DEFAULT_UNSPECIFIED = 0,\n+\tFETCH_DEFAULT_SIMPLE,\n+\tFETCH_DEFAULT_CURRENT\n+};\n+\n extern enum branch_track git_branch_track;\n extern enum rebase_setup_type autorebase;\n extern enum push_default_type push_default;\n+extern enum fetch_default_type fetch_default;\n \n enum object_creation_mode {\n \tOBJECT_CREATION_USES_HARDLINKS = 0,\ndiff --git a/config.c b/config.c\nindex 830ee14..1ce8543 100644\n--- a/config.c\n+++ b/config.c\n@@ -849,6 +849,24 @@ static int git_default_push_config(const char *var, const char *value)\n \treturn 0;\n }\n \n+static int git_default_fetch_config(const char *var, const char *value)\n+{\n+\tif (strcmp(var, \"fetch.default\"))\n+\t\treturn 0;\n+\n+\tif (!value)\n+\t\treturn config_error_nonbool(var);\n+\telse if (!strcmp(value, \"simple\"))\n+\t\tfetch_default = FETCH_DEFAULT_SIMPLE;\n+\telse if (!strcmp(value, \"current\"))\n+\t\tfetch_default = FETCH_DEFAULT_CURRENT;\n+\telse {\n+\t\terror(\"Malformed value for %s: %s\", var, value);\n+\t\treturn error(\"Must be simple, or current.\");\n+\t}\n+\treturn 0;\n+}\n+\n static int git_default_mailmap_config(const char *var, const char *value)\n {\n \tif (!strcmp(var, \"mailmap.file\"))\n@@ -877,6 +895,9 @@ int git_default_config(const char *var, const char *value, void *dummy)\n \tif (!prefixcmp(var, \"push.\"))\n \t\treturn git_default_push_config(var, value);\n \n+\tif (!prefixcmp(var, \"fetch.\"))\n+\t\treturn git_default_fetch_config(var, value);\n+\n \tif (!prefixcmp(var, \"mailmap.\"))\n \t\treturn git_default_mailmap_config(var, value);\n \ndiff --git a/environment.c b/environment.c\nindex e2e75c1..f24873b 100644\n--- a/environment.c\n+++ b/environment.c\n@@ -51,6 +51,7 @@ unsigned whitespace_rule_cfg = WS_DEFAULT_RULE;\n enum branch_track git_branch_track = BRANCH_TRACK_REMOTE;\n enum rebase_setup_type autorebase = AUTOREBASE_NEVER;\n enum push_default_type push_default = PUSH_DEFAULT_UNSPECIFIED;\n+enum fetch_default_type fetch_default = FETCH_DEFAULT_UNSPECIFIED;\n #ifndef OBJECT_CREATION_MODE\n #define OBJECT_CREATION_MODE OBJECT_CREATION_USES_HARDLINKS\n #endif\ndiff --git a/t/t5513-fetch-track.sh b/t/t5513-fetch-track.sh\nindex 65d1e05..dcd4a8b 100755\n--- a/t/t5513-fetch-track.sh\n+++ b/t/t5513-fetch-track.sh\n@@ -27,4 +27,47 @@ test_expect_success fetch '\n \t)\n '\n \n+cat >expected < 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\ttest_cmp ../expected .git/FETCH_HEAD\n+\t)\n+'\n+cat >expected < 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\ttest_cmp ../expected .git/FETCH_HEAD\n+\t)\n+'\n+\n test_done\n-- \n1.8.3.rc2.542.g24820ba\n"},{"id":"217825","messageId":"CALkWK0mGPMw8NuhJFS0gK2BVutRO=FxX1ss+1o8fnndCc13LWw@mail.gmail.com","threadId":"33861","inReplyTo":"1368843536-19781-1-git-send-email-felipe.contreras@gmail.com","subject":"Re: [PATCH] fetch: add new fetch.default configuration","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-05-18T18:43:01Z","receivedAt":"2013-05-18T18:43:01Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Felipe Contreras wrote:\n> % git checkout --set-upstream-to master\n\nWhat is the problem you're trying to solve: why do you want an\nupstream set to master? Is it only because of rebase? We should\nprobably get rebase.defaultUpstream = @{u}|origin|...\n"},{"id":"217831","messageId":"CAMP44s3pZYw87awogjjOdFRP39Ou0=td2erhV2-aC-9_A_Z75A@mail.gmail.com","threadId":"33861","inReplyTo":"CALkWK0mGPMw8NuhJFS0gK2BVutRO=FxX1ss+1o8fnndCc13LWw@mail.gmail.com","subject":"Re: [PATCH] fetch: add new fetch.default configuration","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-05-18T22:20:22Z","receivedAt":"2013-05-18T22:20:22Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sat, May 18, 2013 at 1:43 PM, Ramkumar Ramachandra\n wrote:\n> Felipe Contreras wrote:\n>> % git checkout --set-upstream-to master\n>\n> What is the problem you're trying to solve: why do you want an\n> upstream set to master?\n\nI have explained that multiple times already. I want all my branches\nto have an upstream:\n\n% git config --global branch.autosetupmerge always\n% git checkout -b topic master\n# stuff\n% git rebase -i\n\n> Is it only because of rebase? We should\n> probably get rebase.defaultUpstream = @{u}|origin|...\n\nNo. I want to set upstream by myself.\n\nThis is what I have now:\n\n fc/branch/fast 27cff17 [master] branch: add show-tracking option\n fc/build/cleanups 85b0869 [master] build: do not install\ngit-remote-testpy\n fc/comp/files 4edc621 [master] completion: remove\n__git_index_file_list_filter()\n fc/comp/ls-remote 0d2d2d7 [master] completion: avoid\nls-remote in certain scenarios\n fc/comp/parse eb1c813 [master] completion: Use\nparse-options raw output for simple long options\n fc/comp/zsh-cleanup 4ad3e4f [master] completion: zsh:\nimprove bash script loading\n fc/fast-export/cleanup 1714a14 [master] fast-export: refactor\nget_tags_and_duplicates()\n fc/fast-export/fast-v2 69b24ba [master] fast-{import,export}:\nuse get_sha1_hex() directly\n fc/fetch/default 1939536 [master] fetch: add new\nfetch.default configuration\n fc/head/v4 be582cf [master] Add new @ shortcut for HEAD\n fc/ident-fix 74baf50 [master] ident: don't allow\nimplicit email addresses\n fc/master 5d63a6e [master] travis: update test command\n fc/related/v5 fad98e7 [master] contrib: related: fix\nparsing of rev-list args\n fc/remote-sync 53a1457 [master] remote: add new sync command\n fc/remote/bzr-debug bed1b93 [fc/remote/bzr-next]\nremote-bzr: add debugging information\n fc/remote/bzr-next 1e52047 [next] remote-bzr: add fallback\ncheck for a partial clone\n fc/remote/hg-extra 080301e [fc/remote/hg-next] remote-hg:\nstore extra hg information in notes\n fc/remote/hg-gitifyhg-compat c4eb2b9 [fc/remote/hg-notes] compat:\nremote-hg: use mercurial's username\n fc/remote/hg-next 062400f [master] remote-hg: remove\nfiles before modifications\n fc/remote/hg-notes 2c38768 [fc/remote/hg-next] remote-hg:\nsupport for notes\n fc/remote/hg-pep f19bd8b [fc/remote/hg-next] remote-hg:\nremove unnecessary global definitions\n fc/run-command/simplify a320010 [master] run-command: simplify\nwait_or_whine\n fc/send-email/series-cc-cmd 2cbe0c3 [master] send-email: add\nseries-cc-cmd option\n fc/stage/part-1 24c50f8 [master] Add proper 'stage' command\n fc/stage/part-2 c7d0f70 [master] completion: update\n--staged options\n fc/stage/part-3 4eaea2f [fc/stage/part-2] completion:\nupdate 'git reset' new stage options\n fc/stage/try-1 a4408b9 [master] tmp\n fc/stage/try-2 b29882d [master] doc: use 'stage' for\ncommon commands\n fc/trivial 74e1483 [master] remote: trivial style cleanup\n* fc/upstream 1c5f4a5 [master] Add travis configuration\n fc/zsh/fix 92152c4 [master] completion: trivial fix for zsh\n fc/zsh/sub aa1b1cf [master] completion: zsh: custom commands\n master de3a5c6 [origin/master] Git 1.8.3-rc3\n next 75252d8 [origin/next] Sync with 1.8.3-rc3\n old/remote/hg-next-check d184c81 [master] remote-hg: remove\nfiles before modifications\n stable 4a9a4f0 [origin/master] Git 1.8.2.2\n tmp 0294f83 [origin/next] Merge branch\n'fc/master' into tmp\n tmp2 4170e70 [work] Merge branch 'work' into tmp2\n work 4e7f4b3 [master] tmp\n\nI can do:\n\n% git checkout fc/remote/hg-next\n% git rebase -i # rebase to master\n% git checkout fc/remote/hg-notes\n% git rebase -i # rebase to fc/remote/hg-next\n% git checkout fc/remote/hg-gitifyhg-compat\n% git rebase -i # rebase to fc/remote/hg-notes\n\nI don't have to think about it. The relationship between branches\nmakes everything just work.\n\n-- \nFelipe Contreras\n"},{"id":"217837","messageId":"CAPig+cRtdtqyh5=ENf9UrfTOUtzL2Ut+neXRJqRBFgVKxObyiw@mail.gmail.com","threadId":"33861","inReplyTo":"1368843536-19781-1-git-send-email-felipe.contreras@gmail.com","subject":"Re: [PATCH] fetch: add new fetch.default configuration","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2013-05-19T02:42:29Z","receivedAt":"2013-05-19T02:42:29Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Fri, May 17, 2013 at 10:18 PM, Felipe Contreras\n wrote:\n> When the user has an upstream branch configured to track a remote\n> tracking branch:\n>\n> % git checkout --set-upstream-to github/master\n>\n> Doing a 'git fetch' without any arguments would try to fetch 'github',\n> because it's configured as current branch's remote\n> (branch..remote).\n>\n> However, if we do something slightly different:\n>\n> % git checkout --set-upstream-to master\n>\n> Doing a 'git fetch' without any arguments would try to fetch the remote\n> '.', for the same reason.\n>\n> But, unlike the in the first instance, the second command would not\n> update any remote tracking branch, in fact, it would not update any\n> branch at all. The only effect is that it would update FETCH_HEAD.\n>\n> FETCH_HEAD is a special symbol that is used to store the result of a\n> fetch. It can be used by other commands of git, specially 'git merge'.\n>\n> It is however, barely mentioned in the documentation, and can be\n> considered a plumbing concept at best, that few Git users would benefit\n> from using, and indeed, quite likely very few use it, or are even aware\n> of it.\n>\n> So when the user is presented with a message like this:\n>\n> % git fetch\n> From .\n> * branch master -> FETCH_HEAD\n>\n> The vast majority of them would have absolutely no idea what's going on.\n> Many of them would probably just shrug, and manually specify the remote\n> the want to fetch from, which is 'origin' in many cases.\n\ns/the/they/\n\n> If the user has say, twenty branches, ten with a local upstream\n> (branch..remote = '.'), and ten without an upstream. The user\n> might get used to typing 'git fetch' and expect Git to fetch from\n> 'origin' which would happen 50% of the time, but the other 50%, the user\n> would be forced to specify the remote.\n>\n> This inconsistency would be simply one more to join the list of\n> incomprehensible quirks the user has to put up when using Git, so quite\n\ns/up/up with/\n\n> likely (s)he simply gets used to it, only to complain later in forums or\n> social media, outside of the dwelling distance of the typical Git\n> developer.\n>\n> But we can do better.\n>\n> We can add a new 'fetch.default' configuration variable (one more to\n> join the many necessary to force Git to behave in sane manner), so the\n> user can specify what (s)he wants to be performed when the remote is not\n> specified in the 'git fetch' command.\n>\n> This configuration would probably be welcome by 99% of the user\n> population, who have no clue what FETCH_HEAD is, and do set local\n> upstream branches, only to find out weird inconsistent behavior\n> depending on which branch the happen to be sitting at.\n\ns/the/they/\n\n> We add documentation and testing as expected, and also introduce other\n> changes necessary to make the configuration enter into effect when it's\n> needed.\n>\n> The default (FETCH_DEFAULT_UNSPECIFIED), allows the current behavior to\n> be unmodified, so remote_get(NULL) is called, and the current rules to\n> determine the default branch remain.\n>\n> The new option \"simple\" allows Git to always fetch from \"origin\", which\n> is what most users would expect, and it's 100% consistent.\n>\n> Alternatively, the user can manually specify the current behavior with\n> \"current\" (alluding to the current branch), so that the behavior changes\n> depending on which branch the user happens to be sitting at. This would\n> allow the user to retain this behavior, if (s)he so wishes,\n> in case Git developers regain their sense and set a default that most\n> users would appreciate (\"simple\").\n>\n> If the user wants, for whatever strange reason swimming in his/her head,\n> (s) can still fetch from a local ('.') remote (even stating that as an\n\ns/(s)/(s)he/\n\n> English sentence doesn't make any sense).\n>\n> % git fetch .\n> From .\n> * branch master -> FETCH_HEAD\n>\n> And to any number of weird hacks with FETCH_HEAD.\n>\n> The average user lucky enough to find the 'fetch.default' configuration,\n> however, would never have to enter the word of \"local remote\"\n> strangeness, and would remain comfortably in the place where locals are\n> locals, and remotes are remotes, and 'git fetch' is always consistent,\n> and always does something useful.\n>\n> Signed-off-by: Felipe Contreras \n"},{"id":"217886","messageId":"CALkWK0nQzEK6-E7aMnGg6eYZJ_=XsE6FBmRgu9_8jBGkYmJe+Q@mail.gmail.com","threadId":"33861","inReplyTo":"CAMP44s3pZYw87awogjjOdFRP39Ou0=td2erhV2-aC-9_A_Z75A@mail.gmail.com","subject":"Re: [PATCH] fetch: add new fetch.default configuration","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-05-19T11:51:12Z","receivedAt":"2013-05-19T11:51:12Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Felipe Contreras wrote:\n> % git checkout fc/remote/hg-next\n> % git rebase -i # rebase to master\n> % git checkout fc/remote/hg-notes\n> % git rebase -i # rebase to fc/remote/hg-next\n> % git checkout fc/remote/hg-gitifyhg-compat\n> % git rebase -i # rebase to fc/remote/hg-notes\n\nSo it is rebase, but rebase.defaultUpstream = origin won't suffice.\nYou want to specify a custom base. What I don't understand is why\nyou're abusing @{u}, and crippling remote (by hard-interpreting it as\n\"origin\") to achieve this. For the record, I didn't think your\nbranch..base was a bad idea at all (re-visiting now).\n"},{"id":"217902","messageId":"CAMP44s1rV+Pe_58qZLvTDt-r7XkDAinh3npY-dr+W5vnfNk4NA@mail.gmail.com","threadId":"33861","inReplyTo":"CALkWK0nQzEK6-E7aMnGg6eYZJ_=XsE6FBmRgu9_8jBGkYmJe+Q@mail.gmail.com","subject":"Re: [PATCH] fetch: add new fetch.default configuration","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-05-19T12:15:33Z","receivedAt":"2013-05-19T12:15:33Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sun, May 19, 2013 at 6:51 AM, Ramkumar Ramachandra\n wrote:\n> Felipe Contreras wrote:\n>> % git checkout fc/remote/hg-next\n>> % git rebase -i # rebase to master\n>> % git checkout fc/remote/hg-notes\n>> % git rebase -i # rebase to fc/remote/hg-next\n>> % git checkout fc/remote/hg-gitifyhg-compat\n>> % git rebase -i # rebase to fc/remote/hg-notes\n>\n> So it is rebase, but rebase.defaultUpstream = origin won't suffice.\n> You want to specify a custom base. What I don't understand is why\n> you're abusing @{u},\n\nThere's no abuse; 'upstream' is meant *exactly* for this: rebase, and pull.\n\nIt's called upstream because that's where eventually all the code must\ngo, so semantically it's *exactly* correct: 'origin/master' is the\nupstream of 'master' which is the upstream of 'fc/remote/hg-next',\nwhich is the upstream of 'fc/remote/hg-notes', and so on.\n\nAnd if I where to merge a branch from 'master', it make sense that the\ndefault is 'origin/master', because that's the upstream.\n\nLiterally each and every way in which 'upstream' is used remains the\nsame for local branches, except for 'git push'.\n\n> and crippling remote (by hard-interpreting it as\n> \"origin\") to achieve this.\n\nMore false rhetoric; \"origin\" is *ALREADY* the default.\n\nShow me the output of these:\n\n%git clone --origin foobar git://git.kernel.org/pub/scm/git/git.git /tmp/git\n%cd /tmp/git\n%git fetch -v\n%git checkout --no-track -b test master\n%git fetch -v\n\n> For the record, I didn't think your\n> branch..base was a bad idea at all (re-visiting now).\n\nIt makes sens for rebase, but what happens when you do 'git pull' and\nyou don't have an upstream configured, only a base? Why would you want\n'git pull' to fail? In which instances would you want to have a\n'base', but not an 'upstream'?\n\nThink about it.\n\n-- \nFelipe Contreras\n"},{"id":"217903","messageId":"CALkWK0=poS43aGYuMzEP9K7e0P0khFRnzQxihtgAvh3rtb9Mdw@mail.gmail.com","threadId":"33861","inReplyTo":"CAMP44s1rV+Pe_58qZLvTDt-r7XkDAinh3npY-dr+W5vnfNk4NA@mail.gmail.com","subject":"Re: [PATCH] fetch: add new fetch.default configuration","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-05-19T12:26:17Z","receivedAt":"2013-05-19T12:26:17Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"My itch is very simple.\n\nFelipe Contreras wrote:\n> % git checkout fc/remote/hg-next\n> % git rebase -i # rebase to master\n\n% git pull # I want: pull from origin\n\n> % git checkout fc/remote/hg-notes\n> % git rebase -i # rebase to fc/remote/hg-next\n\n% git pull # I want: pull from ram\n\n> % git checkout fc/remote/hg-gitifyhg-compat\n> % git rebase -i # rebase to fc/remote/hg-notes\n\n% git pull # I want: pull from felipe\n\nWith your series, rebase works and I like that. But, by specifying\nbranch..remote as '.', I've essentially lost a way to specify a\nremote I want. Why can't I have both?\n"},{"id":"217905","messageId":"CAMP44s0p067aR4XKqrNimdsp2GrYa42mdnarTZoSGFuNdgy1dA@mail.gmail.com","threadId":"33861","inReplyTo":"CALkWK0=poS43aGYuMzEP9K7e0P0khFRnzQxihtgAvh3rtb9Mdw@mail.gmail.com","subject":"Re: [PATCH] fetch: add new fetch.default configuration","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-05-19T12:37:14Z","receivedAt":"2013-05-19T12:37:14Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sun, May 19, 2013 at 7:26 AM, Ramkumar Ramachandra\n wrote:\n> My itch is very simple.\n>\n> Felipe Contreras wrote:\n>> % git checkout fc/remote/hg-next\n>> % git rebase -i # rebase to master\n>\n> % git pull # I want: pull from origin\n\nThen do 'git pull origin', 'fc/remote/hg-next' has *nothing* to do with origin.\n\n>> % git checkout fc/remote/hg-notes\n>> % git rebase -i # rebase to fc/remote/hg-next\n>\n> % git pull # I want: pull from ram\n\nDitto.\n\n>> % git checkout fc/remote/hg-gitifyhg-compat\n>> % git rebase -i # rebase to fc/remote/hg-notes\n>\n> % git pull # I want: pull from felipe\n\nDitto.\n\n> With your series, rebase works and I like that. But, by specifying\n> branch..remote as '.',\n\nI'm not doing that *GIT* is doing that.\n\nWhat does this throw?\n% git checkout --track -b foo master\n% git config branch.foo.remote\n\n> I've essentially lost a way to specify a\n> remote I want. Why can't I have both?\n\nYou haven't lost anything. The upstream is\n'branch.x.remote'+'branch.x.merge', and it remains so before and after\nthis patch. You can set 'branch.x.remote' to whatever you want.\n\n-- \nFelipe Contreras\n"},{"id":"219137","messageId":"CAMP44s1_yQ+y5eupd3vbhDi6be+vhkj8cSw4K2kxn5wDMFQwgA@mail.gmail.com","threadId":"33861","inReplyTo":"1368843536-19781-1-git-send-email-felipe.contreras@gmail.com","subject":"Re: [PATCH] fetch: add new fetch.default configuration","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-01T14:04:09Z","receivedAt":"2013-06-01T14:04:09Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Fri, May 17, 2013 at 9:18 PM, Felipe Contreras\n wrote:\n> When the user has an upstream branch configured to track a remote\n> tracking branch:\n>\n> % git checkout --set-upstream-to github/master\n>\n> Doing a 'git fetch' without any arguments would try to fetch 'github',\n> because it's configured as current branch's remote\n> (branch..remote).\n>\n> However, if we do something slightly different:\n>\n> % git checkout --set-upstream-to master\n>\n> Doing a 'git fetch' without any arguments would try to fetch the remote\n> '.', for the same reason.\n\nWhat happened to this? Didn't you want big commit messages?\n\n-- \nFelipe Contreras\n"}]}