{"thread":{"id":"35615","subject":"[PATCH 1/2] completion: complete format.coverLetter","startedAt":"2014-01-06T17:18:50Z","lastAt":"2014-04-10T19:20:01Z","messageCount":37,"participants":["Ramkumar Ramachandra","Jonathan Nieder","Junio C Hamano","Jeff King","John Szakmeister","Felipe Contreras"],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"232731","messageId":"1389028732-27760-1-git-send-email-artagnon@gmail.com","threadId":"35615","inReplyTo":null,"subject":"[PATCH 0/2] Minor convinience feature: format.defaultTo","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2014-01-06T17:18:50Z","receivedAt":"2014-01-06T17:18:50Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Hi,\n\nThis is inspired by merge.defaultToUpstream. Disclaimer: I have an\n\"fpm\" alias for doing this (separate from \"fp\" for when I need to\ngenerate patches against some other branch), which I'd like to get rid\nof.\n\nThanks.\n\nRamkumar Ramachandra (2):\n completion: complete format.coverLetter\n format-patch: introduce format.defaultTo\n\n Documentation/config.txt | 4 ++++\n builtin/log.c | 7 +++++++\n contrib/completion/git-completion.bash | 2 ++\n t/t4014-format-patch.sh | 10 ++++++++++\n 4 files changed, 23 insertions(+)\n\n-- \n1.8.5.2.229.g4448466.dirty\n"},{"id":"232730","messageId":"1389028732-27760-2-git-send-email-artagnon@gmail.com","threadId":"35615","inReplyTo":"1389028732-27760-1-git-send-email-artagnon@gmail.com","subject":"[PATCH 1/2] completion: complete format.coverLetter","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2014-01-06T17:18:51Z","receivedAt":"2014-01-06T17:18:51Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Signed-off-by: Ramkumar Ramachandra \n---\n contrib/completion/git-completion.bash | 1 +\n 1 file changed, 1 insertion(+)\n\ndiff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\nindex 51c2dd4..39b81f7 100644\n--- a/contrib/completion/git-completion.bash\n+++ b/contrib/completion/git-completion.bash\n@@ -1991,6 +1991,7 @@ _git_config ()\n \t\tfetch.unpackLimit\n \t\tformat.attach\n \t\tformat.cc\n+\t\tformat.coverLetter\n \t\tformat.headers\n \t\tformat.numbered\n \t\tformat.pretty\n-- \n1.8.5.2.229.g4448466.dirty\n"},{"id":"232732","messageId":"1389028732-27760-3-git-send-email-artagnon@gmail.com","threadId":"35615","inReplyTo":"1389028732-27760-1-git-send-email-artagnon@gmail.com","subject":"[PATCH 2/2] format-patch: introduce format.defaultTo","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2014-01-06T17:18:52Z","receivedAt":"2014-01-06T17:18:52Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"A very common workflow for preparing patches involves working off a\ntopic branch and generating patches against 'master' to send off to the\nmaintainer. However, a plain\n\n $ git format-patch -o outgoing\n\nis a no-op on a topic branch, and the user has to remember to specify\n'master' explicitly everytime. Save the user the extra keystrokes by\nintroducing format.defaultTo which can contain the name of a branch\nagainst which to base patches.\n\nSigned-off-by: Ramkumar Ramachandra \n---\n Documentation/config.txt | 4 ++++\n builtin/log.c | 7 +++++++\n contrib/completion/git-completion.bash | 1 +\n t/t4014-format-patch.sh | 10 ++++++++++\n 4 files changed, 22 insertions(+)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex a405806..b90abd1 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -1135,6 +1135,10 @@ format.coverLetter::\n \tformat-patch is invoked, but in addition can be set to \"auto\", to\n \tgenerate a cover-letter only when there's more than one patch.\n \n+format.defaultTo::\n+\tThe name of a branch against which to generate patches by\n+\tdefault. You'd usually want this to be 'master'.\n+\n filter..clean::\n \tThe command which is used to convert the content of a worktree\n \tfile to a blob upon checkin. See linkgit:gitattributes[5] for\ndiff --git a/builtin/log.c b/builtin/log.c\nindex b97373d..ebc419e 100644\n--- a/builtin/log.c\n+++ b/builtin/log.c\n@@ -674,6 +674,7 @@ static int thread;\n static int do_signoff;\n static const char *signature = git_version_string;\n static int config_cover_letter;\n+static const char *config_defaultto;\n \n enum {\n \tCOVER_UNSET,\n@@ -750,6 +751,8 @@ static int git_format_config(const char *var, const char *value, void *cb)\n \t\tconfig_cover_letter = git_config_bool(var, value) ? COVER_ON : COVER_OFF;\n \t\treturn 0;\n \t}\n+\tif (!strcmp(var, \"format.defaultto\"))\n+\t\treturn git_config_string(&config_defaultto, var, value);\n \n \treturn git_log_config(var, value, cb);\n }\n@@ -1324,6 +1327,10 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)\n \t\tdie (_(\"--subject-prefix and -k are mutually exclusive.\"));\n \trev.preserve_subject = keep_subject;\n \n+\tif (argc < 2 && config_defaultto) {\n+\t\targv[1] = config_defaultto;\n+\t\targc++;\n+\t}\n \targc = setup_revisions(argc, argv, &rev, &s_r_opt);\n \tif (argc > 1)\n \t\tdie (_(\"unrecognized argument: %s\"), argv[1]);\ndiff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\nindex 39b81f7..75699d4 100644\n--- a/contrib/completion/git-completion.bash\n+++ b/contrib/completion/git-completion.bash\n@@ -1992,6 +1992,7 @@ _git_config ()\n \t\tformat.attach\n \t\tformat.cc\n \t\tformat.coverLetter\n+\t\tformat.defaultTo\n \t\tformat.headers\n \t\tformat.numbered\n \t\tformat.pretty\ndiff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh\nindex 73194b2..46c0337 100755\n--- a/t/t4014-format-patch.sh\n+++ b/t/t4014-format-patch.sh\n@@ -1370,4 +1370,14 @@ test_expect_success 'cover letter auto user override' '\n \ttest_line_count = 2 list\n '\n \n+test_expect_success 'defaultTo side' '\n+\tmkdir -p tmp &&\n+\ttest_when_finished \"rm -rf tmp;\n+\t\tgit config --unset format.defaultTo\" &&\n+\n+\tgit config format.defaultTo side &&\n+\tgit format-patch -o tmp >list &&\n+\ttest_line_count = 3 list\n+'\n+\n test_done\n-- \n1.8.5.2.229.g4448466.dirty\n"},{"id":"232735","messageId":"CALkWK0k2ATGKtJ-93J1WL4vjSK6=hUZvciawTVHpsrwBd1ETHg@mail.gmail.com","threadId":"35615","inReplyTo":"1389028732-27760-1-git-send-email-artagnon@gmail.com","subject":"Re: [PATCH 0/2] Minor convinience feature: format.defaultTo","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2014-01-06T17:25:32Z","receivedAt":"2014-01-06T17:25:32Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Ramkumar Ramachandra wrote:\n> Ramkumar Ramachandra (2):\n> completion: complete format.coverLetter\n> format-patch: introduce format.defaultTo\n\nAny thoughts on checkout.defaultTo? I have a \"com\" alias to checkout 'master'.\n"},{"id":"232745","messageId":"20140106183548.GG3881@google.com","threadId":"35615","inReplyTo":"1389028732-27760-3-git-send-email-artagnon@gmail.com","subject":"Re: [PATCH 2/2] format-patch: introduce format.defaultTo","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2014-01-06T18:35:48Z","receivedAt":"2014-01-06T18:35:48Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nRamkumar Ramachandra wrote:\n\n> a plain\n>\n> $ git format-patch -o outgoing\n>\n> is a no-op on a topic branch, and the user has to remember to specify\n> 'master' explicitly everytime. Save the user the extra keystrokes by\n> introducing format.defaultTo\n\nNot excited. Two reasons:\n\n 1. Most config settings are in noun form: e.g.,\n \"[remote] pushDefault = foo\". That makes their names easy to guess\n and makes them easy to talk about: I set the default remote for\n pushing by changing the remote.pushdefault setting.\n\n '[url \"\"] insteadOf' is an exception to that and a bit of an\n aberration.\n\n This new '[format] defaultTo' repeats the same end-with-a-preposition\n mistake, while I think it would be better to learn from it.\n\n 2. Wouldn't a more natural default be @{u}..HEAD instead of relying on\n the user to do the make-work of keeping a local branch that tracks\n master up to date?\n\nHope that helps,\nJonathan\n"},{"id":"232746","messageId":"xmqqlhythrzq.fsf@gitster.dls.corp.google.com","threadId":"35615","inReplyTo":"1389028732-27760-3-git-send-email-artagnon@gmail.com","subject":"Re: [PATCH 2/2] format-patch: introduce format.defaultTo","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-01-06T18:42:17Z","receivedAt":"2014-01-06T18:42:17Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramkumar Ramachandra writes:\n\n> A very common workflow for preparing patches involves working off a\n> topic branch and generating patches against 'master' to send off to the\n> maintainer. However, a plain\n>\n> $ git format-patch -o outgoing\n>\n> is a no-op on a topic branch,...\n\nTwo points.\n\n - why is a single branch name sufficient?\n\n - is it a better option to simply default to @{u}, if one exists,\n instead of failing?\n"},{"id":"232748","messageId":"CALkWK0kZn44x98td9YXNT5VfhVs=ueeSty9M7Vh08bdoGjGQYg@mail.gmail.com","threadId":"35615","inReplyTo":"xmqqlhythrzq.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH 2/2] format-patch: introduce format.defaultTo","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2014-01-06T18:49:02Z","receivedAt":"2014-01-06T18:49:02Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Junio C Hamano wrote:\n> - why is a single branch name sufficient?\n\nIt does accept a , so any form is allowed; but why would\nanyone want that in a format.defaultTo? I'm not sure we want to impose\nan artificial restriction on the configuration variable though.\n\n> - is it a better option to simply default to @{u}, if one exists,\n> instead of failing?\n\nI'm not sure @{u} is a good default. Personally, my workflow involves\npublishing my fork before sending out patches; mainly so that I can\ncompare with @{u} when I do re-spins. People can put @{u} in\nformat.defaultTo if it suits their workflow though.\n"},{"id":"232751","messageId":"CALkWK0m3wQ7=fDOO5q3-h1T+ScFp7c29jtaDWq_0W37RVLsWdg@mail.gmail.com","threadId":"35615","inReplyTo":"20140106183548.GG3881@google.com","subject":"Re: [PATCH 2/2] format-patch: introduce format.defaultTo","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2014-01-06T19:02:09Z","receivedAt":"2014-01-06T19:02:09Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Jonathan Nieder wrote:\n> 1. Most config settings are in noun form: e.g.,\n> \"[remote] pushDefault = foo\". That makes their names easy to guess\n> and makes them easy to talk about: I set the default remote for\n> pushing by changing the remote.pushdefault setting.\n>\n> '[url \"\"] insteadOf' is an exception to that and a bit of an\n> aberration.\n>\n> This new '[format] defaultTo' repeats the same end-with-a-preposition\n> mistake, while I think it would be better to learn from it.\n\nI agree that it's somewhat unconventional to allow people to put a\n as a configuration variable value, but I think it's useful.\nurl..insteadOf is incredibly useful, for instance.\n\n> 2. Wouldn't a more natural default be @{u}..HEAD instead of relying on\n> the user to do the make-work of keeping a local branch that tracks\n> master up to date?\n\nLike I said in my message to Junio, @{u} is not necessarily the \"best\"\ndefault for all workflows, although you can fill that into\nformat.defaultTo.\n"},{"id":"232756","messageId":"xmqqa9f8j2n8.fsf@gitster.dls.corp.google.com","threadId":"35615","inReplyTo":"CALkWK0kZn44x98td9YXNT5VfhVs=ueeSty9M7Vh08bdoGjGQYg@mail.gmail.com","subject":"Re: [PATCH 2/2] format-patch: introduce format.defaultTo","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-01-06T20:06:51Z","receivedAt":"2014-01-06T20:06:51Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramkumar Ramachandra writes:\n\n> Junio C Hamano wrote:\n>> - why is a single branch name sufficient?\n>\n> It does accept a , so any form is allowed; but why would\n> anyone want that in a format.defaultTo? I'm not sure we want to impose\n> an artificial restriction on the configuration variable though.\n\nI meant \"a single branch\" as opposed to \"depending on what branch\nyou are sending out, you may have to use a different upstream\nstarting point\", and a single \"format.defaultTo\" that does not read\nwhat your HEAD currently points at may not be enough.\n\nUnless you set @{u} to this new configuration, in which case the\nchoice becomes dynamic depending on the current branch, but\n\n - if that is the only sane choice based on the current branch, why\n not use that as the default without having to set the\n configuration?\n\n - Or if that is still insufficient, don't we need branch.*.forkedFrom\n that is different from branch.*.merge, so that different branches\n you want to show \"format-patch\" output can have different\n reference points?\n\nAfter all, \"format-patch\" to send things out to upstream is like\nasking the other side to do a \"rebase\" you would do in your\nrepository, so whatever \"git rebase\" that were too lazy to specify\nwhat the fork point was when applying may be a reasonable type-saver\ndefault. Yes, sometimes people need to rebase onto somewhere they\ndid not fork from, but that is why they can give explicit $upstream\nand $onto to the command---I do not think it is any different for\n\"format-patch\".\n"},{"id":"232758","messageId":"20140106201854.GA28162@sigill.intra.peff.net","threadId":"35615","inReplyTo":"xmqqa9f8j2n8.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH 2/2] format-patch: introduce format.defaultTo","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-01-06T20:18:54Z","receivedAt":"2014-01-06T20:18:54Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jan 06, 2014 at 12:06:51PM -0800, Junio C Hamano wrote:\n\n> Unless you set @{u} to this new configuration, in which case the\n> choice becomes dynamic depending on the current branch, but\n> \n> - if that is the only sane choice based on the current branch, why\n> not use that as the default without having to set the\n> configuration?\n> \n> - Or if that is still insufficient, don't we need branch.*.forkedFrom\n> that is different from branch.*.merge, so that different branches\n> you want to show \"format-patch\" output can have different\n> reference points?\n\nYeah, I had similar thoughts. I personally use \"branch.*.merge\" as\n\"forkedFrom\", and it seems like we are going that way anyway with things\nlike \"git rebase\" and \"git merge\" defaulting to upstream. But then there\nis \"git push -u\" and \"push.default = upstream\", which treats the\nupstream config as something else entirely.\n\nSo it seems like there is already some confusion, and either way we go,\nthisis making it worse to some degree (I do not blame Ram, but rather he\nhas stumbled into a hidden sand pit that we have been building for the\npast few years... :).\n\nI wonder if it is too late to try to clarify this dual usage. It kind of\nseems like the push config is \"this is the place I publish to\". Which,\nin many workflows, just so happens to be the exact same as the place you\nforked from. Could we introduce a new branch.*.pushupstream variable\nthat falls back to branch.*.merge? Or is that just throwing more fuel on\nthe fire (more sand in the pit in my analogy, I guess).\n\nI admit I haven't thought it through yet, though. And even if it does\nwork, it may throw a slight monkey wrench in the proposed push.default\ntransition.\n\n-Peff\n"},{"id":"232759","messageId":"CAEBDL5UaS2Hd-Yb417W+Fw_7j1+5sRAgszko-PbU7z901_X+cw@mail.gmail.com","threadId":"35615","inReplyTo":"20140106201854.GA28162@sigill.intra.peff.net","subject":"Re: [PATCH 2/2] format-patch: introduce format.defaultTo","fromName":"John Szakmeister","fromEmail":"john@szakmeister.net","sentAt":"2014-01-06T20:29:57Z","receivedAt":"2014-01-06T20:29:57Z","isPatch":true,"sender":{"key":"john@szakmeister.net","avatar":"https://avatars.githubusercontent.com/u/448087?v=4"},"body":"On Mon, Jan 6, 2014 at 3:18 PM, Jeff King wrote:\n> On Mon, Jan 06, 2014 at 12:06:51PM -0800, Junio C Hamano wrote:\n>\n>> Unless you set @{u} to this new configuration, in which case the\n>> choice becomes dynamic depending on the current branch, but\n>>\n>> - if that is the only sane choice based on the current branch, why\n>> not use that as the default without having to set the\n>> configuration?\n>>\n>> - Or if that is still insufficient, don't we need branch.*.forkedFrom\n>> that is different from branch.*.merge, so that different branches\n>> you want to show \"format-patch\" output can have different\n>> reference points?\n>\n> Yeah, I had similar thoughts. I personally use \"branch.*.merge\" as\n> \"forkedFrom\", and it seems like we are going that way anyway with things\n> like \"git rebase\" and \"git merge\" defaulting to upstream. But then there\n> is \"git push -u\" and \"push.default = upstream\", which treats the\n> upstream config as something else entirely.\n\nJust for more reference, I rarely use \"branch.*.merge\" as\n\"forkedFrom\". I typically want to use master as my target, but like\nRam, I publish my changes elsewhere for safe keeping. I think in a\ntypical, feature branch-based workflow @{u} would be nearly useless.\n\n-John\n"},{"id":"232760","messageId":"xmqq1u0kj16h.fsf@gitster.dls.corp.google.com","threadId":"35615","inReplyTo":"20140106201854.GA28162@sigill.intra.peff.net","subject":"Re: [PATCH 2/2] format-patch: introduce format.defaultTo","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-01-06T20:38:30Z","receivedAt":"2014-01-06T20:38:30Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Mon, Jan 06, 2014 at 12:06:51PM -0800, Junio C Hamano wrote:\n>\n>> Unless you set @{u} to this new configuration, in which case the\n>> choice becomes dynamic depending on the current branch, but\n>> \n>> - if that is the only sane choice based on the current branch, why\n>> not use that as the default without having to set the\n>> configuration?\n>> \n>> - Or if that is still insufficient, don't we need branch.*.forkedFrom\n>> that is different from branch.*.merge, so that different branches\n>> you want to show \"format-patch\" output can have different\n>> reference points?\n>\n> Yeah, I had similar thoughts. I personally use \"branch.*.merge\" as\n> \"forkedFrom\", and it seems like we are going that way anyway with things\n> like \"git rebase\" and \"git merge\" defaulting to upstream. But then there\n> is \"git push -u\" and \"push.default = upstream\", which treats the\n> upstream config as something else entirely.\n>\n> So it seems like there is already some confusion, and either way we go,\n> thisis making it worse to some degree (I do not blame Ram, but rather he\n> has stumbled into a hidden sand pit that we have been building for the\n> past few years... :).\n>\n> I wonder if it is too late to try to clarify this dual usage. It kind of\n> seems like the push config is \"this is the place I publish to\". Which,\n> in many workflows, just so happens to be the exact same as the place you\n> forked from. Could we introduce a new branch.*.pushupstream variable\n> that falls back to branch.*.merge? Or is that just throwing more fuel on\n> the fire (more sand in the pit in my analogy, I guess).\n>\n> I admit I haven't thought it through yet, though. And even if it does\n> work, it may throw a slight monkey wrench in the proposed push.default\n> transition.\n\nYeah, when I say \"upstream\", I never mean it as \"where I publish\".\nYour upstream is where you get others' work from.\n\nFor a \"push to somewhere for safekeeping or other people to look at\"\ntriangular workflow, it does not make any sense to treat that \"I\npublish there\" place as an upstream (hence having branch.*.remote\npointing at that publishing point). Once you stop doing that, and\ninstead using branch.*.remote = origin, and branch.*.merge = master,\nwhere 'origin' is not your publishing point, @{u} will again start\nmaking sense, I think.\n\nAnd I thought that is what setting \"remote.pushdefault\" to the\npublishing point repository was about.\n"},{"id":"232762","messageId":"20140106204203.GI3881@google.com","threadId":"35615","inReplyTo":"CAEBDL5UaS2Hd-Yb417W+Fw_7j1+5sRAgszko-PbU7z901_X+cw@mail.gmail.com","subject":"Re: [PATCH 2/2] format-patch: introduce format.defaultTo","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2014-01-06T20:42:03Z","receivedAt":"2014-01-06T20:42:03Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"John Szakmeister wrote:\n\n> I think in a\n> typical, feature branch-based workflow @{u} would be nearly useless.\n\nI thought the idea of @{u} was that it represents which ref one\ntypically wants to compare the current branch to. It is used by\n'git branch -v' to show how far ahead or behind a branch is and\nused by 'git pull --rebase' to forward-port a branch, for example.\n\nSo a topic branch with @{u} pointing to 'master' or 'origin/master'\nseems pretty normal and hopefully the shortcuts it allows can make\nlife more convenient.\n\nIt is *not* primarily about where the branch gets pushed. After all,\nin both the 'matching' and the 'simple' mode, \"git push\" does not push\nthe current branch to its upstream @{u} unless @{u} happens to have\nthe same name.\n\nHoping that clarifies,\nJonathan\n"},{"id":"232763","messageId":"20140106204353.GB643@sigill.intra.peff.net","threadId":"35615","inReplyTo":"CAEBDL5UaS2Hd-Yb417W+Fw_7j1+5sRAgszko-PbU7z901_X+cw@mail.gmail.com","subject":"Re: [PATCH 2/2] format-patch: introduce format.defaultTo","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-01-06T20:43:54Z","receivedAt":"2014-01-06T20:43:54Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jan 06, 2014 at 03:29:57PM -0500, John Szakmeister wrote:\n\n> > Yeah, I had similar thoughts. I personally use \"branch.*.merge\" as\n> > \"forkedFrom\", and it seems like we are going that way anyway with things\n> > like \"git rebase\" and \"git merge\" defaulting to upstream. But then there\n> > is \"git push -u\" and \"push.default = upstream\", which treats the\n> > upstream config as something else entirely.\n> \n> Just for more reference, I rarely use \"branch.*.merge\" as\n> \"forkedFrom\". I typically want to use master as my target, but like\n> Ram, I publish my changes elsewhere for safe keeping. I think in a\n> typical, feature branch-based workflow @{u} would be nearly useless.\n\nIn my feature-branch development for git.git, my upstream is almost\nalways origin/master[1]. However, sometimes feature branches have\ndependencies[2] on each other. Representing that via the \"upstream\"\nfield makes sense, since that is what you forked from, and what you\nwould want \"git rebase\" to start from.\n\n-Peff\n\n[1] I do not even have a local \"master\" branch for git.git work, as it\n would just be a pain to keep up to date. I am either working\n directly on a topic branch, or I am integrating in my own personal\n branch.\n\n[2] You should try to minimize dependencies between feature branches, of\n course, but sometimes they simply form a logical progression of\n features.\n"},{"id":"232764","messageId":"20140106205526.GC643@sigill.intra.peff.net","threadId":"35615","inReplyTo":"xmqq1u0kj16h.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH 2/2] format-patch: introduce format.defaultTo","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-01-06T20:55:26Z","receivedAt":"2014-01-06T20:55:26Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jan 06, 2014 at 12:38:30PM -0800, Junio C Hamano wrote:\n\n> > I wonder if it is too late to try to clarify this dual usage. It kind of\n> > seems like the push config is \"this is the place I publish to\". Which,\n> > in many workflows, just so happens to be the exact same as the place you\n> > forked from. Could we introduce a new branch.*.pushupstream variable\n> > that falls back to branch.*.merge? Or is that just throwing more fuel on\n> > the fire (more sand in the pit in my analogy, I guess).\n> >\n> > I admit I haven't thought it through yet, though. And even if it does\n> > work, it may throw a slight monkey wrench in the proposed push.default\n> > transition.\n> \n> Yeah, when I say \"upstream\", I never mean it as \"where I publish\".\n> Your upstream is where you get others' work from.\n\nThat's my thinking, as well, but it means the \"upstream\" push.default is\nnonsensical. I've thought that all along, but it seems like other people\nfind it useful. I guess because they are in a non-triangular,\nnon-feature-branch setup (I suppose you could think of a central-repo\nfeature-branch workflow as a special form of triangular setup, where\nthe remote is bi-directional, but the branch names are triangular).\n\nIf we want to declare \"push -u\" and \"push.default=upstream\" as tools for\ncertain simple bi-directional workflows, that makes sense. But I suspect\nit may cause extra confusion when people make the jump to using a\ntriangular workflow.\n\n> For a \"push to somewhere for safekeeping or other people to look at\"\n> triangular workflow, it does not make any sense to treat that \"I\n> publish there\" place as an upstream (hence having branch.*.remote\n> pointing at that publishing point).\n\nYou _might_ treat it the same way we treat the upstream, in some special\ncases. For example, when you say \"git status\", it is useful to see how\nyour topic and the upstream have progressed (i.e., do I need to pull\nfrom upstream?). But you may _also_ want to know how your local branch\ndiffers from its pushed counterpart (i.e., do I have unsaved commits\nhere that I want to push up?).\n\nSo having two config options might help with that. Of course, your \"push\nupstream\" (or whatever you want to call it) does not logically have one\nvalue. You may push to several places, and would want to compare to\neach.\n\n> Once you stop doing that, and\n> instead using branch.*.remote = origin, and branch.*.merge = master,\n> where 'origin' is not your publishing point, @{u} will again start\n> making sense, I think.\n> \n> And I thought that is what setting \"remote.pushdefault\" to the\n> publishing point repository was about.\n\nIf that were sufficient, then we would just need \"push.default =\ncurrent\", and not \"upstream\" (nor \"simple\"). I lobbied for that during\nthe discussion, but people seemed to think that \"upstream\" was\nbetter/more useful. Maybe it was just because remote.pushdefault did not\nexist then.\n\n-Peff\n"},{"id":"232765","messageId":"CAEBDL5VD9C8DXFUS9VawxZhAC0AnR=abV-FEVTdi25NVBPvDVg@mail.gmail.com","threadId":"35615","inReplyTo":"20140106204203.GI3881@google.com","subject":"Re: [PATCH 2/2] format-patch: introduce format.defaultTo","fromName":"John Szakmeister","fromEmail":"john@szakmeister.net","sentAt":"2014-01-06T21:13:44Z","receivedAt":"2014-01-06T21:13:44Z","isPatch":true,"sender":{"key":"john@szakmeister.net","avatar":"https://avatars.githubusercontent.com/u/448087?v=4"},"body":"On Mon, Jan 6, 2014 at 3:42 PM, Jonathan Nieder wrote:\n> John Szakmeister wrote:\n>\n>> I think in a\n>> typical, feature branch-based workflow @{u} would be nearly useless.\n>\n> I thought the idea of @{u} was that it represents which ref one\n> typically wants to compare the current branch to. It is used by\n> 'git branch -v' to show how far ahead or behind a branch is and\n> used by 'git pull --rebase' to forward-port a branch, for example.\n>\n> So a topic branch with @{u} pointing to 'master' or 'origin/master'\n> seems pretty normal and hopefully the shortcuts it allows can make\n> life more convenient.\n\nIs there an outline of this git workflow in the documentation\nsomewhere? Do you save your work in a forked repo anywhere? If so,\nhow do you typically save your work. I typically have my @{u}\npointing to where I save my work. Perhaps I'm missing something\nimportant here, but I don't feel like the current command set and\ntypical workflow (at least those in tutorials) leads you in that\ndirection.\n\nHere is one example:\n \n\n> It is *not* primarily about where the branch gets pushed. After all,\n> in both the 'matching' and the 'simple' mode, \"git push\" does not push\n> the current branch to its upstream @{u} unless @{u} happens to have\n> the same name.\n\nThen where does it get pushed? Do you always specify where to save your work?\n\nFWIW, I think the idea of treating @{u} as the eventual recipient of\nyour changes is good, but then it seems like Git is lacking the\n\"publish my changes to this other branch\" concept.\n\nAm I missing something? If there is something other than @{u} to\nrepresent this latter concept, I think `git push` should default to\nthat instead. But, at least with my current knowledge, that doesn't\nexist--without explicitly saying so--or treating @{u} as that branch.\nIf there's a better way to do this, I'd love to hear it!\n\nThanks!\n\n-John\n"},{"id":"232767","messageId":"xmqqwqichkm0.fsf@gitster.dls.corp.google.com","threadId":"35615","inReplyTo":"20140106205526.GC643@sigill.intra.peff.net","subject":"Re: [PATCH 2/2] format-patch: introduce format.defaultTo","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-01-06T21:21:43Z","receivedAt":"2014-01-06T21:21:43Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Mon, Jan 06, 2014 at 12:38:30PM -0800, Junio C Hamano wrote:\n>\n>> > I wonder if it is too late to try to clarify this dual usage. It kind of\n>> > seems like the push config is \"this is the place I publish to\". Which,\n>> > in many workflows, just so happens to be the exact same as the place you\n>> > forked from. Could we introduce a new branch.*.pushupstream variable\n>> > that falls back to branch.*.merge? Or is that just throwing more fuel on\n>> > the fire (more sand in the pit in my analogy, I guess).\n>> >\n>> > I admit I haven't thought it through yet, though. And even if it does\n>> > work, it may throw a slight monkey wrench in the proposed push.default\n>> > transition.\n>> \n>> Yeah, when I say \"upstream\", I never mean it as \"where I publish\".\n>> Your upstream is where you get others' work from.\n>\n> That's my thinking, as well, but it means the \"upstream\" push.default is\n> nonsensical. I've thought that all along, but it seems like other people\n> find it useful. I guess because they are in a non-triangular,\n> non-feature-branch setup (I suppose you could think of a central-repo\n> feature-branch workflow as a special form of triangular setup, where\n> the remote is bi-directional, but the branch names are triangular).\n>\n> If we want to declare \"push -u\" and \"push.default=upstream\" as\n> tools for certain simple bi-directional workflows, that makes\n> sense. But I suspect it may cause extra confusion when people\n> make the jump to using a triangular workflow.\n\nI do not think there is no \"want to declare\" involved. If I\ncorrectly recall how \"push -u\" came about, it was merely a way to\nappease those who complained that their new branch created by\nrunning \"checkout -b branch origin/branch\" has already set up the\nbranch.*.remote and branch.*.merge configurations nicely for them\nand allow them to immediately go ahead and start using the\ncentralized \"I merge from their 'branch' and push to that\", but when\nthey create a new branch on their own and want to make the branch of\nthe same name at the origin to be the \"upstream\", they have to futz\nwith the configuration. The declaration was made long time ago when\nwe started using @{upstream}, and there is no new extra confusion.\n\n>> For a \"push to somewhere for safekeeping or other people to look at\"\n>> triangular workflow, it does not make any sense to treat that \"I\n>> publish there\" place as an upstream (hence having branch.*.remote\n>> pointing at that publishing point).\n>\n> You _might_ treat it the same way we treat the upstream, in some special\n> cases. For example, when you say \"git status\", it is useful to see how\n> your topic and the upstream have progressed (i.e., do I need to pull\n> from upstream?). But you may _also_ want to know how your local branch\n> differs from its pushed counterpart (i.e., do I have unsaved commits\n> here that I want to push up?).\n\nCorrect; I am not saying \"where do I publish\" is never relevant. It\nis just it is not something useful for \"format-patch\" to use as the\ndefault fork-point.\n\n> So having two config options might help with that. Of course, your \"push\n> upstream\" (or whatever you want to call it) does not logically have one\n> value. You may push to several places, and would want to compare to\n> each.\n\nYes. But most likely, if you always push a single branch to\nmultiple places, it won't be like you push it to only one of the\nplaces today and another one tomorrow, leaving everybody out of\nsync. Unless there is a site that is temporarily down, in which\ncase that one may stay behind, the normal state would be that all of\nthem point at the same commit (that is how I publish to multiple\nplaces anyway).\n\n>> Once you stop doing that, and\n>> instead using branch.*.remote = origin, and branch.*.merge = master,\n>> where 'origin' is not your publishing point, @{u} will again start\n>> making sense, I think.\n>> \n>> And I thought that is what setting \"remote.pushdefault\" to the\n>> publishing point repository was about.\n>\n> If that were sufficient, then we would just need \"push.default =\n> current\", and not \"upstream\" (nor \"simple\"). I lobbied for that during\n> the discussion, but people seemed to think that \"upstream\" was\n> better/more useful. Maybe it was just because remote.pushdefault did not\n> exist then.\n\nYeah, I think in the 2.0 world with pushdefault (i.e. triangular),\nthe default 'simple' turns into 'current'.\n"},{"id":"232769","messageId":"xmqqlhyshjwc.fsf@gitster.dls.corp.google.com","threadId":"35615","inReplyTo":"CAEBDL5VD9C8DXFUS9VawxZhAC0AnR=abV-FEVTdi25NVBPvDVg@mail.gmail.com","subject":"Re: [PATCH 2/2] format-patch: introduce format.defaultTo","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-01-06T21:37:07Z","receivedAt":"2014-01-06T21:37:07Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"John Szakmeister writes:\n\n> Am I missing something? If there is something other than @{u} to\n> represent this latter concept, I think `git push` should default to\n> that instead. But, at least with my current knowledge, that doesn't\n> exist--without explicitly saying so--or treating @{u} as that branch.\n> If there's a better way to do this, I'd love to hear it!\n\nI see Ram who worked on landing the remote.pushdefault feature is\nCC'ed; this work was started in early April 2013 and your config and\nworkflow may not have been adjusted to it.\n"},{"id":"232772","messageId":"CALkWK0nSed9vvRvTR00_vV3tHL8mSQA=8JJ_Y7=pQchoVcvhzA@mail.gmail.com","threadId":"35615","inReplyTo":"xmqqa9f8j2n8.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH 2/2] format-patch: introduce format.defaultTo","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2014-01-06T21:59:39Z","receivedAt":"2014-01-06T21:59:39Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Junio C Hamano wrote:\n> I meant \"a single branch\" as opposed to \"depending on what branch\n> you are sending out, you may have to use a different upstream\n> starting point\", and a single \"format.defaultTo\" that does not read\n> what your HEAD currently points at may not be enough.\n>\n> Unless you set @{u} to this new configuration, in which case the\n> choice becomes dynamic depending on the current branch, but\n>\n> - if that is the only sane choice based on the current branch, why\n> not use that as the default without having to set the\n> configuration?\n>\n> - Or if that is still insufficient, don't we need branch.*.forkedFrom\n> that is different from branch.*.merge, so that different branches\n> you want to show \"format-patch\" output can have different\n> reference points?\n\nAh, I was going for an equivalent of merge.defaultToUpstream, but I\nguess branch.*.forkedFrom is a good way to go.\n"},{"id":"232774","messageId":"CALkWK0k21W4gz9Rm8CyLMwjXq2A9wvm=XCVDsqs06oeW3VUg6w@mail.gmail.com","threadId":"35615","inReplyTo":"20140106201854.GA28162@sigill.intra.peff.net","subject":"Re: [PATCH 2/2] format-patch: introduce format.defaultTo","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2014-01-06T22:10:56Z","receivedAt":"2014-01-06T22:10:56Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Jeff King wrote:\n> Yeah, I had similar thoughts. I personally use \"branch.*.merge\" as\n> \"forkedFrom\", and it seems like we are going that way anyway with things\n> like \"git rebase\" and \"git merge\" defaulting to upstream.\n\nMy issue with that is that I no idea where my branch is with respect\nto my forked upstream; I find that extremely useful when doing\nre-spins.\n\n> But then there\n> is \"git push -u\" and \"push.default = upstream\", which treats the\n> upstream config as something else entirely.\n\npush.default = upstream is a bit of a disaster, in my opinion. I've\nadvocated push.default = current on multiple occasions, and wrote the\ninitial remote.pushDefault series with that configuration in mind.\n\n> I wonder if it is too late to try to clarify this dual usage. It kind of\n> seems like the push config is \"this is the place I publish to\". Which,\n> in many workflows, just so happens to be the exact same as the place you\n> forked from. Could we introduce a new branch.*.pushupstream variable\n> that falls back to branch.*.merge? Or is that just throwing more fuel on\n> the fire (more sand in the pit in my analogy, I guess).\n\nWe already have a branch.*.pushremote, and I don't see the value of\nbranch.*.pushbranch (what you're referring to as pushupstream, I\nassume) except for Gerrit users. Frankly, I don't use full triangular\nworkflows myself mainly because my prompt is compromised: when I have\na branch.*.remote different from branch.*.pushremote, I'd like to see\nwhere my branch is with respect to @{u} and @{publish} (not yet\ninvented); that's probably too much information to digest anyway, so I\nuse central workflow (pointing to my fork) for each of my branches,\nexcept master (which points to Junio's repo).\n\n> I admit I haven't thought it through yet, though. And even if it does\n> work, it may throw a slight monkey wrench in the proposed push.default\n> transition.\n\nWe're transitioning to push.default = simple which is even simpler than current.\n"},{"id":"232776","messageId":"xmqqha9ghhrw.fsf@gitster.dls.corp.google.com","threadId":"35615","inReplyTo":"CALkWK0nSed9vvRvTR00_vV3tHL8mSQA=8JJ_Y7=pQchoVcvhzA@mail.gmail.com","subject":"Re: [PATCH 2/2] format-patch: introduce format.defaultTo","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-01-06T22:22:59Z","receivedAt":"2014-01-06T22:22:59Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramkumar Ramachandra writes:\n\n> Junio C Hamano wrote:\n>> I meant \"a single branch\" as opposed to \"depending on what branch\n>> you are sending out, you may have to use a different upstream\n>> starting point\", and a single \"format.defaultTo\" that does not read\n>> what your HEAD currently points at may not be enough.\n>>\n>> Unless you set @{u} to this new configuration, in which case the\n>> choice becomes dynamic depending on the current branch, but\n>>\n>> - if that is the only sane choice based on the current branch, why\n>> not use that as the default without having to set the\n>> configuration?\n>>\n>> - Or if that is still insufficient, don't we need branch.*.forkedFrom\n>> that is different from branch.*.merge, so that different branches\n>> you want to show \"format-patch\" output can have different\n>> reference points?\n>\n> Ah, I was going for an equivalent of merge.defaultToUpstream, but I\n> guess branch.*.forkedFrom is a good way to go.\n\nAs I said in the different subthread, I am not convinced that you\nwould need the complexity of branch.*.forkedFrom. If you set your\n\"upstream\" to the true upstream (not your publishing point), and\nhave \"remote.pushdefault\" set to 'publish', you can expect\n\n\tgit push\n\nto do the right thing, and then always say\n\n\tgit show-branch publish/topic topic\n\nto see where your last published branch is relative to what you\nhave, no? Mapping \"topic@{publish}\" to \"refs/remotes/publish/topic\"\n(or when you have 'topic' checked out, mapping \"@{publish}\" to it)\nis a trivial but is a separate usefulness, I would guess.\n"},{"id":"232778","messageId":"CALkWK0=Km+a7NBm9ki5MN=R28HkzUZRqnBKcpuPZDrQKdsBesg@mail.gmail.com","threadId":"35615","inReplyTo":"xmqqha9ghhrw.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH 2/2] format-patch: introduce format.defaultTo","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2014-01-06T22:47:00Z","receivedAt":"2014-01-06T22:47:00Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Junio C Hamano wrote:.\n> As I said in the different subthread, I am not convinced that you\n> would need the complexity of branch.*.forkedFrom. If you set your\n> \"upstream\" to the true upstream (not your publishing point), and\n> have \"remote.pushdefault\"set to 'publish', you can expect\n>\n> git push\n>\n> to do the right thing, and then always say\n>\n> git show-branch publish/topic topic\n\nI think it's highly sub-optimal to have a local-branch @{u} for\nseveral reasons; the prompt is almost useless in this case, and it\nwill always show your forked-branch ahead of 'master' (assuming that\n'master' doesn't update itself in the duration of your development).\nWhile doing respins, the prompt doesn't aid you in any way. Besides,\non several occasions, I found myself working on the same forked-branch\nfrom two different machines; then the publish-point isn't necessarily\nalways a publish-point: it's just another \"upstream\" for the branch.\nThe point of a special branch.*.forkedFrom is that you can always show\nthe \"master..@\" information in the prompt ignoring divergences; after\nall, a divergence simply means that you need to rebase onto the latest\n'master' ('master' is never going to get a non-ff update anyway).\n\nSo, instead of crippling the functionality around the publish-point,\nlet's build minimal required functionality around branch.*.forkedFrom.\nI'd love a prompt like:\n\n branch-forkedfrom<>5*:~/src/git$\n\nClearly, branch-forkedfrom has diverged from my publish-point (I'm\nprobably doing a respin), and has 5 commits (it's 5 commits ahead of\n'master' ignoring divergences).\n\n> to see where your last published branch is relative to what you\n> have, no? Mapping \"topic@{publish}\" to \"refs/remotes/publish/topic\"\n> (or when you have 'topic' checked out, mapping \"@{publish}\" to it)\n> is a trivial but is a separate usefulness, I would guess.\n\nI think a @{publish} is needed for when branch.*.remote is different\nfrom remote.pushDefault. Like I said earlier, it's probably too much\ninformation to give to the user: divergences with respect to two\nremotes. So, we'll hold it off until someone finds a usecase for it.\n"},{"id":"232779","messageId":"CALkWK0mQJcFw45uWz08h+gzn6rTdVOdHkUtU3oRTyQ00LbtcbA@mail.gmail.com","threadId":"35615","inReplyTo":"CAEBDL5VD9C8DXFUS9VawxZhAC0AnR=abV-FEVTdi25NVBPvDVg@mail.gmail.com","subject":"Re: [PATCH 2/2] format-patch: introduce format.defaultTo","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2014-01-06T22:54:59Z","receivedAt":"2014-01-06T22:54:59Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"John Szakmeister wrote:\n> Then where does it get pushed? Do you always specify where to save your work?\n>\n> FWIW, I think the idea of treating @{u} as the eventual recipient of\n> your changes is good, but then it seems like Git is lacking the\n> \"publish my changes to this other branch\" concept.\n>\n> Am I missing something? If there is something other than @{u} to\n> represent this latter concept, I think `git push` should default to\n> that instead. But, at least with my current knowledge, that doesn't\n> exist--without explicitly saying so--or treating @{u} as that branch.\n> If there's a better way to do this, I'd love to hear it!\n\nThat's why we invented remote.pushdefault and branch.*.pushremote. When you say\n\n $ git push\n\nit automatically goes to the right remote instead of going to the\nplace you fetched from. You can read up on how push.default interacts\nwith this setting too, although I always recommend push.default =\ncurrent.\n"},{"id":"232791","messageId":"CAEBDL5W+3zRb1c51N2JfTR2acwvrUi8TpOw-DkjUn_r114mhAA@mail.gmail.com","threadId":"35615","inReplyTo":"CALkWK0mQJcFw45uWz08h+gzn6rTdVOdHkUtU3oRTyQ00LbtcbA@mail.gmail.com","subject":"Re: [PATCH 2/2] format-patch: introduce format.defaultTo","fromName":"John Szakmeister","fromEmail":"john@szakmeister.net","sentAt":"2014-01-07T00:42:45Z","receivedAt":"2014-01-07T00:42:45Z","isPatch":true,"sender":{"key":"john@szakmeister.net","avatar":"https://avatars.githubusercontent.com/u/448087?v=4"},"body":"On Mon, Jan 6, 2014 at 5:54 PM, Ramkumar Ramachandra wrote:\n> John Szakmeister wrote:\n>> Then where does it get pushed? Do you always specify where to save your work?\n>>\n>> FWIW, I think the idea of treating @{u} as the eventual recipient of\n>> your changes is good, but then it seems like Git is lacking the\n>> \"publish my changes to this other branch\" concept.\n>>\n>> Am I missing something? If there is something other than @{u} to\n>> represent this latter concept, I think `git push` should default to\n>> that instead. But, at least with my current knowledge, that doesn't\n>> exist--without explicitly saying so--or treating @{u} as that branch.\n>> If there's a better way to do this, I'd love to hear it!\n>\n> That's why we invented remote.pushdefault and branch.*.pushremote. When you say\n>\n> $ git push\n>\n> it automatically goes to the right remote instead of going to the\n> place you fetched from. You can read up on how push.default interacts\n> with this setting too, although I always recommend push.default =\n> current.\n\nThis was the piece that I was missing. I remember when\nremote.pushdefault was added, but questioned its usefulness because it\njust changes the remote that a branch is pushed to, not necessarily\nthe name. I somehow missed the 'current' option for 'push.default'...\nwhich is surprising since I seem to spend an incredible amount of time\nlooking at the git-config man page. I guess it's not a good idea to\nset 'push.default' to 'upstream' in this triangle workflow then,\notherwise the branch name being pushed to will be 'branch.*.merge'.\nIs that correct? I just want to make sure I understand what's\nhappening here.\n\nGiven this new found knowledge, I'm not sure it makes sense for `git\nstatus` to show me the status against the upstream vs. the publish\nlocation. The latter makes a little more sense to me, though I see\nthe usefulness of either one.\n\nThanks for taking the time to explain this. I'm going to have to\nspend some more time with this configuration and see what the sticking\npoints are.\n\n-John\n"},{"id":"232806","messageId":"CALkWK0=DTB629jUZfQceeEZjjR4RK-b-xBqaTN2+HUG8VGP_0Q@mail.gmail.com","threadId":"35615","inReplyTo":"1389028732-27760-2-git-send-email-artagnon@gmail.com","subject":"Re: [PATCH 1/2] completion: complete format.coverLetter","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2014-01-07T11:24:27Z","receivedAt":"2014-01-07T11:24:27Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Ramkumar Ramachandra wrote:\n> contrib/completion/git-completion.bash | 1 +\n> 1 file changed, 1 insertion(+)\n\nJunio: Please push this part via 'maint' independently.\n"},{"id":"232809","messageId":"CALkWK0=VT_MaLJKzhRyrEjG_PH=rEGiMuyHeuEXpSqgeVLqjuA@mail.gmail.com","threadId":"35615","inReplyTo":"CAEBDL5W+3zRb1c51N2JfTR2acwvrUi8TpOw-DkjUn_r114mhAA@mail.gmail.com","subject":"Re: [PATCH 2/2] format-patch: introduce format.defaultTo","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2014-01-07T16:47:46Z","receivedAt":"2014-01-07T16:47:46Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"John Szakmeister wrote:\n> I guess it's not a good idea to\n> set 'push.default' to 'upstream' in this triangle workflow then,\n> otherwise the branch name being pushed to will be 'branch.*.merge'.\n> Is that correct? I just want to make sure I understand what's\n> happening here.\n\npush.default = upstream does not support triangular workflows. See\nbuiltin/push.c:setup_push_upstream().\n\n> Given this new found knowledge, I'm not sure it makes sense for `git\n> status` to show me the status against the upstream vs. the publish\n> location. The latter makes a little more sense to me, though I see\n> the usefulness of either one.\n\nCurrently, status information is only against @{u}; we haven't\ninvented a @{publish} yet.\n"},{"id":"232852","messageId":"20140107205618.GA28102@sigill.intra.peff.net","threadId":"35615","inReplyTo":"CALkWK0k21W4gz9Rm8CyLMwjXq2A9wvm=XCVDsqs06oeW3VUg6w@mail.gmail.com","subject":"Re: [PATCH 2/2] format-patch: introduce format.defaultTo","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-01-07T20:56:18Z","receivedAt":"2014-01-07T20:56:18Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jan 07, 2014 at 03:40:56AM +0530, Ramkumar Ramachandra wrote:\n\n> Jeff King wrote:\n> > Yeah, I had similar thoughts. I personally use \"branch.*.merge\" as\n> > \"forkedFrom\", and it seems like we are going that way anyway with things\n> > like \"git rebase\" and \"git merge\" defaulting to upstream.\n> \n> My issue with that is that I no idea where my branch is with respect\n> to my forked upstream; I find that extremely useful when doing\n> re-spins.\n\nRight. I think there are two separate relationships, and they are both\nshoe-horned into \"upstream\". The solution is to let them be configured\nseparately (and fallback on each other as appropriate to make the burden\nless on the user).\n\n> push.default = upstream is a bit of a disaster, in my opinion. I've\n> advocated push.default = current on multiple occasions, and wrote the\n> initial remote.pushDefault series with that configuration in mind.\n\nYeah, I agree with all of that.\n\n> > I wonder if it is too late to try to clarify this dual usage. It kind of\n> > seems like the push config is \"this is the place I publish to\". Which,\n> > in many workflows, just so happens to be the exact same as the place you\n> > forked from. Could we introduce a new branch.*.pushupstream variable\n> > that falls back to branch.*.merge? Or is that just throwing more fuel on\n> > the fire (more sand in the pit in my analogy, I guess).\n> \n> We already have a branch.*.pushremote, and I don't see the value of\n> branch.*.pushbranch (what you're referring to as pushupstream, I\n> assume) except for Gerrit users.\n\nYes, \"pushbranch\" is probably a better name for what I am referring to.\nI agree that pushremote is probably enough for sane cases. I seem to\nrecall that people advocating the \"upstream\" push-default thought that\nbranch name mapping was a useful feature, but I might be\nmis-remembering. I will let those people speak up for the feature if\nthey see fit; it seems somewhat crazy to me.\n\n> Frankly, I don't use full triangular workflows myself mainly because\n> my prompt is compromised: when I have a branch.*.remote different from\n> branch.*.pushremote, I'd like to see where my branch is with respect\n> to @{u} and @{publish} (not yet invented);\n\nYes, as two separate relationships, you would theoretically want to be\nable to see them separately (or simultaneously side by side). Whether\nexposing that in the prompt is too clunky, I don't know (I don't even\nshow ahead/behind in my prompt, but rather prefer to query it when I\ncare; I have a separate script that queries the ahead/behind against my\npublishing point, but it would be nice if git handled this itself).\n\n> > I admit I haven't thought it through yet, though. And even if it does\n> > work, it may throw a slight monkey wrench in the proposed push.default\n> > transition.\n> \n> We're transitioning to push.default = simple which is even simpler\n> than current.\n\nSimpler in the sense that it is less likely to do something unexpected.\nBut the rules are actually more complicated. Two examples:\n\n 1. Imagine I make a feature branch \"foo\" forked off of origin/master, then\n \"git push\" with no arguments. The \"current\" scheme would go to\n \"foo\" on origin, but \"upstream\" would go to \"master\". Since they\n don't agree, \"simple\" will punt and tell me to be more specific.\n\n 2. Imagine I have set my default push remote to \"publish\", am on\n master (forked from \"origin/master\") and I run \"git push\" without\n arguments. \"current\" would push to \"master\" on \"publish\". But\n \"upstream\" will complain, because we are not pushing to our\n upstream remote. I believe \"simple\" will therefore reject this.\n\nIn both cases, I think \"current\" does the sane thing, and \"simple\" makes\nthings more complicated. The one saving grace it has is that it punts on\nthese cases rather than potentially doing something destructive that the\nuser did not intend.\n\n-Peff\n"},{"id":"232854","messageId":"20140107210607.GB28102@sigill.intra.peff.net","threadId":"35615","inReplyTo":"CALkWK0=Km+a7NBm9ki5MN=R28HkzUZRqnBKcpuPZDrQKdsBesg@mail.gmail.com","subject":"Re: [PATCH 2/2] format-patch: introduce format.defaultTo","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-01-07T21:06:07Z","receivedAt":"2014-01-07T21:06:07Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jan 07, 2014 at 04:17:00AM +0530, Ramkumar Ramachandra wrote:\n\n> Junio C Hamano wrote:.\n> > As I said in the different subthread, I am not convinced that you\n> > would need the complexity of branch.*.forkedFrom. If you set your\n> > \"upstream\" to the true upstream (not your publishing point), and\n> > have \"remote.pushdefault\"set to 'publish', you can expect\n> >\n> > git push\n> >\n> > to do the right thing, and then always say\n> >\n> > git show-branch publish/topic topic\n> \n> I think it's highly sub-optimal to have a local-branch @{u} for\n> several reasons; the prompt is almost useless in this case, and it\n> will always show your forked-branch ahead of 'master' (assuming that\n> 'master' doesn't update itself in the duration of your development).\n\nI actually use local-branch @{u} all the time to represent inter-topic\ndependencies. For example, imagine I have topic \"bar\" which builds on\ntopic \"foo\", which is based on master. I would have:\n\n [branch \"foo\"]\n remote = origin\n merge = refs/heads/master\n [branch \"bar\"]\n remote = .\n merge = refs/heads/foo\n\nWhen I rebase \"foo\", I want to rebase it against upstream's master. When\nI rebase \"bar\", I want to rebase it against foo. And naturally, upstream\ndoes not necessarily have a \"foo\", because it is my topic, not theirs (I\n_may_ have published my \"foo\" somewhere, but that is orthogonal, and\nanyway my local \"foo\" is the most up-to-date source, not the pushed\nversion).\n\nAs an aside, if you want to rebase both branches, you have to topo-sort\nthem to make sure you do \"foo\" first, then rebase \"bar\" on the result.\nMy daily procedure is something like:\n\n all_topics |\n while read topic; do \"echo $topic $(git rev-parse $topic@{u})\"; done |\n topo_sort |\n while read topic upstream; do\n git rebase $upstream $topic || exit 1\n done\n\n> While doing respins, the prompt doesn't aid you in any way. Besides,\n> on several occasions, I found myself working on the same forked-branch\n> from two different machines; then the publish-point isn't necessarily\n> always a publish-point: it's just another \"upstream\" for the branch.\n\nRight, things get trickier then. But I don't think there is an automatic\nway around that. Sometimes the published one is more up to date, and\nsometimes the upstream thing is more up to date. You have to manually\ntell git which you are currently basing your work on. I find in such a\nsituation that it tends to resolve itself quickly, though, as the first\nstep is to pull in the changes you pushed up from the other machine\nanyway (either via \"git reset\" or \"git rebase\").\n\n-Peff\n"},{"id":"232855","messageId":"xmqqvbxvbiwz.fsf@gitster.dls.corp.google.com","threadId":"35615","inReplyTo":"20140107205618.GA28102@sigill.intra.peff.net","subject":"Re: [PATCH 2/2] format-patch: introduce format.defaultTo","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-01-07T21:07:08Z","receivedAt":"2014-01-07T21:07:08Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> Yes, \"pushbranch\" is probably a better name for what I am referring to.\n> I agree that pushremote is probably enough for sane cases. I seem to\n> recall that people advocating the \"upstream\" push-default thought that\n> branch name mapping was a useful feature, but I might be\n> mis-remembering. I will let those people speak up for the feature if\n> they see fit; it seems somewhat crazy to me.\n\nI think \"branch mapping\" you recall are for those who want to push\ntheir 'topic' to 'review/topic' or something like that. With Git\npost 7cdebd8a (Merge branch 'jc/push-refmap', 2013-12-27), I think\n\"remote.*.push\" can be used to implement that, by the way.\n\n>> Frankly, I don't use full triangular workflows myself mainly because\n>> my prompt is compromised: when I have a branch.*.remote different from\n>> branch.*.pushremote, I'd like to see where my branch is with respect\n>> to @{u} and @{publish} (not yet invented);\n>\n> Yes, as two separate relationships, you would theoretically want to be\n> able to see them separately (or simultaneously side by side). Whether\n> exposing that in the prompt is too clunky, I don't know (I don't even\n> show ahead/behind in my prompt, but rather prefer to query it when I\n> care; I have a separate script that queries the ahead/behind against my\n> publishing point, but it would be nice if git handled this itself).\n\nSame here. I do not bother a/b in prompt and comparison with\npublishing point is done with a custom script. It would be nice to\nhave it natively, and @{publish} would be a good first step to do\nso.\n"},{"id":"232857","messageId":"20140107212432.GD28102@sigill.intra.peff.net","threadId":"35615","inReplyTo":"xmqqvbxvbiwz.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH 2/2] format-patch: introduce format.defaultTo","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-01-07T21:24:32Z","receivedAt":"2014-01-07T21:24:32Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jan 07, 2014 at 01:07:08PM -0800, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > Yes, \"pushbranch\" is probably a better name for what I am referring to.\n> > I agree that pushremote is probably enough for sane cases. I seem to\n> > recall that people advocating the \"upstream\" push-default thought that\n> > branch name mapping was a useful feature, but I might be\n> > mis-remembering. I will let those people speak up for the feature if\n> > they see fit; it seems somewhat crazy to me.\n> \n> I think \"branch mapping\" you recall are for those who want to push\n> their 'topic' to 'review/topic' or something like that. With Git\n> post 7cdebd8a (Merge branch 'jc/push-refmap', 2013-12-27), I think\n> \"remote.*.push\" can be used to implement that, by the way.\n\nHmm. The top patch of that series still relies on \"upstream\" being a\npush destination, though. So if I have a triangular workflow where I\nfork \"topic\" from \"origin/master\", my \"git push origin topic\" will go to\n\"refs/heads/master\" on \"origin\" under the \"upstream\" rule. So that seems\nbroken as ever. :)\n\nBut I guess what you are referring to is that in a triangular world, the\nsecond patch lets me do:\n\n git config push.default current\n git config remote.origin.push 'refs/heads/*:refs/review/*'\n\nAnd then \"git push\", \"git push origin\", or \"git push origin topic\" all\nput it in \"review/topic\", which is what I want.\n\nI think that is sensible, and only heightens my sense of the \"upstream\"\npush.default as useless. :)\n\n-Peff\n"},{"id":"232858","messageId":"CALkWK0==wNMvjHmwnGaQi+RitXgros39+70zWH29=Q238Rkp5A@mail.gmail.com","threadId":"35615","inReplyTo":"20140107210607.GB28102@sigill.intra.peff.net","subject":"Re: [PATCH 2/2] format-patch: introduce format.defaultTo","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2014-01-07T21:25:04Z","receivedAt":"2014-01-07T21:25:04Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Jeff King wrote:\n> My daily procedure is something like:\n>\n> all_topics |\n> while read topic; do \"echo $topic $(git rev-parse $topic@{u})\"; done |\n> topo_sort |\n> while read topic upstream; do\n> git rebase $upstream $topic || exit 1\n> done\n\nAh, I was perhaps over-specializing for my own usecase, where\neverything is based off 'master'. I never considered 'master' a \"true\nupstream\" because I throw away topic branches after the maintainer\nmerges them. If you have long-running branches that you work on a\ndaily basis, the issue is somewhat different.\n\n>> While doing respins, the prompt doesn't aid you in any way. Besides,\n>> on several occasions, I found myself working on the same forked-branch\n>> from two different machines; then the publish-point isn't necessarily\n>> always a publish-point: it's just another \"upstream\" for the branch.\n>\n> Right, things get trickier then. But I don't think there is an automatic\n> way around that. Sometimes the published one is more up to date, and\n> sometimes the upstream thing is more up to date. You have to manually\n> tell git which you are currently basing your work on. I find in such a\n> situation that it tends to resolve itself quickly, though, as the first\n> step is to pull in the changes you pushed up from the other machine\n> anyway (either via \"git reset\" or \"git rebase\").\n\nMy primary concern is that the proposed @{publish} should be a\nfirst-class citizen; if it has everything that @{u} has, then we're\nboth good: you'd primarily use @{u}, while I'd primarily use\n@{publish}.\n"},{"id":"232860","messageId":"20140107213052.GA28798@sigill.intra.peff.net","threadId":"35615","inReplyTo":"CALkWK0==wNMvjHmwnGaQi+RitXgros39+70zWH29=Q238Rkp5A@mail.gmail.com","subject":"Re: [PATCH 2/2] format-patch: introduce format.defaultTo","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-01-07T21:30:52Z","receivedAt":"2014-01-07T21:30:52Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Jan 08, 2014 at 02:55:04AM +0530, Ramkumar Ramachandra wrote:\n\n> Jeff King wrote:\n> > My daily procedure is something like:\n> >\n> > all_topics |\n> > while read topic; do \"echo $topic $(git rev-parse $topic@{u})\"; done |\n> > topo_sort |\n> > while read topic upstream; do\n> > git rebase $upstream $topic || exit 1\n> > done\n> \n> Ah, I was perhaps over-specializing for my own usecase, where\n> everything is based off 'master'. I never considered 'master' a \"true\n> upstream\" because I throw away topic branches after the maintainer\n> merges them. If you have long-running branches that you work on a\n> daily basis, the issue is somewhat different.\n\nWhat I do is maybe somewhat gross, but I continually rebase my patches\nforward as master develops. So they diverge from where Junio has forked\nthem upstream (which does not necessarily have any relationship with\nwhere I forked from, anyway). The nice thing about this is that\neventually the topic becomes empty, as rebase drops patches that were\nmerged upstream (or resolve conflicts to end up at an empty patch).\n\nIt's a nice way of tracking the progress of the patch upstream, and it\ncatches any differences between what's upstream and what's in the topic\n(in both directions: you see where the maintainer may have marked up\nyour patch, and you may see a place where you added something to be\nsquashed but the maintainer missed it). The downside is that sometimes\nthe conflicts are annoying and complicated (e.g., several patches that\ntouch the same spot are a pain to rebase on top of themselves; the early\nones are confused that the later changes are already in place).\n\n> My primary concern is that the proposed @{publish} should be a\n> first-class citizen; if it has everything that @{u} has, then we're\n> both good: you'd primarily use @{u}, while I'd primarily use\n> @{publish}.\n\nDefinitely. I think that's the world we want to work towards.\n\n-Peff\n"},{"id":"232867","messageId":"xmqqr48jbg6j.fsf@gitster.dls.corp.google.com","threadId":"35615","inReplyTo":"20140107212432.GD28102@sigill.intra.peff.net","subject":"Re: [PATCH 2/2] format-patch: introduce format.defaultTo","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-01-07T22:06:12Z","receivedAt":"2014-01-07T22:06:12Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> I think that is sensible, and only heightens my sense of the \"upstream\"\n> push.default as useless. :)\n\nYes, it only is good for centralized world (it was designed back in\nthe centralized days after all, wasn't it?).\n"},{"id":"232873","messageId":"20140107221719.GE28102@sigill.intra.peff.net","threadId":"35615","inReplyTo":"xmqqr48jbg6j.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH 2/2] format-patch: introduce format.defaultTo","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-01-07T22:17:19Z","receivedAt":"2014-01-07T22:17:19Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jan 07, 2014 at 02:06:12PM -0800, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > I think that is sensible, and only heightens my sense of the \"upstream\"\n> > push.default as useless. :)\n> \n> Yes, it only is good for centralized world (it was designed back in\n> the centralized days after all, wasn't it?).\n\nI do not think there is any \"centralized days\". From day one, Linus\nadvocated a triangular workflow, and that is how git and kernel develop\nhas always been done. And that is why the default of \"matching\" was\nthere.\n\nThere were people who came later, and who still exist today, who use git\nin an SVN-like centralized way. So if there were centralized days, we\nare in them now. :)\n\nI just do not see any real advantage even in a centralized world for\n\"upstream\" versus \"current\". Before remote.pushdefault, I can\npotentially see some use (if you want to abuse @{upstream}), but now I\ndo not see any point.\n\nAnd even in a centralized workflow, I see \"upstream\" creating problems.\nE.g., you fork a feature branch in the centralized repo; it should not\nget pushed straight back to \"master\"! And that is why we invented\n\"simple\", to prevent such things.\n\nI dunno. I have not gone back and read all of the arguments around\npush.default from last year. It is entirely possible everything I just\nsaid was refuted back then, and I am needlessly rehashing old arguments.\nI remember that Matthieu was one of the main advocates of \"upstream\". I\nam cc-ing him here to bring his attention (not just to this message, but\nto the whole thread).\n\n-Peff\n"},{"id":"232875","messageId":"xmqqmwj7bf73.fsf@gitster.dls.corp.google.com","threadId":"35615","inReplyTo":"20140107221719.GE28102@sigill.intra.peff.net","subject":"Re: [PATCH 2/2] format-patch: introduce format.defaultTo","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-01-07T22:27:28Z","receivedAt":"2014-01-07T22:27:28Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> And even in a centralized workflow, I see \"upstream\" creating problems.\n> E.g., you fork a feature branch in the centralized repo; it should not\n> get pushed straight back to \"master\"! And that is why we invented\n> \"simple\", to prevent such things.\n\nOh, don't get me wrong. I personally wouldn't imagine forking\n'topic' from the shared 'master', call the result perfect and push\nit directly back to the shared 'master'. But the 'upstream' setting\nwas added exactly to support that.\n\nIn such a case, I would have 'master' that is forked from the shared\n'master', 'topic' that is forked from my 'master', and pushing back\nwould be a two-step process, first updating my 'master' in sync with\nthe shared 'master', merging 'topic' into it to make sure the result\nis sane and then push it back to the shared 'master'. And in that\nset-up, 'upstream' would work fine as the upstream of my 'master' is\nthe shared 'master', even though 'current' or even 'matching' would\nwork just as well. So in that sense, I do not see 'upstream' as so\nbroken as you seem to be saying.\n\nOne gap in that line of thought might be that I am sane enough not\nto attempt \"git push\" while I am on my 'topic', though.\n"},{"id":"238653","messageId":"5346ee59d7881_d98135b30ce7@nysa.notmuch","threadId":"35615","inReplyTo":"CALkWK0k21W4gz9Rm8CyLMwjXq2A9wvm=XCVDsqs06oeW3VUg6w@mail.gmail.com","subject":"Re: [PATCH 2/2] format-patch: introduce format.defaultTo","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-10T19:17:45Z","receivedAt":"2014-04-10T19:17:45Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Ramkumar Ramachandra wrote:\n> We already have a branch.*.pushremote, and I don't see the value of\n> branch.*.pushbranch (what you're referring to as pushupstream, I assume)\n> except for Gerrit users. Frankly, I don't use full triangular workflows\n> myself mainly because my prompt is compromised: when I have a branch.*.remote\n> different from branch.*.pushremote, I'd like to see where my branch is with\n> respect to @{u} and @{publish} (not yet invented);\n\n@{publish} not yet invented? I sent this back in October:\n\nhttp://article.gmane.org/gmane.comp.version-control.git/235981\n\n-- \nFelipe Contreras\n"},{"id":"238655","messageId":"5346eee1dfb6_d98135b30c21@nysa.notmuch","threadId":"35615","inReplyTo":"CALkWK0==wNMvjHmwnGaQi+RitXgros39+70zWH29=Q238Rkp5A@mail.gmail.com","subject":"Re: [PATCH 2/2] format-patch: introduce format.defaultTo","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-10T19:20:01Z","receivedAt":"2014-04-10T19:20:01Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Ramkumar Ramachandra wrote:\n> My primary concern is that the proposed @{publish} should be a first-class\n> citizen; if it has everything that @{u} has, then we're both good: you'd\n> primarily use @{u}, while I'd primarily use @{publish}.\n\nSomething like this?\n\nhttp://article.gmane.org/gmane.comp.version-control.git/246038\n\n-- \nFelipe Contreras\n"}]}