{"thread":{"id":"55877","subject":"[PATCH] doc: merge: mention default of defaulttoupstream","startedAt":"2021-06-08T01:59:24Z","lastAt":"2021-06-08T07:29:18Z","messageCount":3,"participants":["Felipe Contreras","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"426690","messageId":"20210608015807.906101-1-felipe.contreras@gmail.com","threadId":"55877","inReplyTo":null,"subject":"[PATCH] doc: merge: mention default of defaulttoupstream","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-06-08T01:58:07Z","receivedAt":"2021-06-08T01:59:24Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Commit a01f7f2ba0 (merge: enable defaulttoupstream by default,\n2014-04-20) forgot to mention the new default in the configuration\ndocumentation.\n\nSigned-off-by: Felipe Contreras \n---\n Documentation/config/merge.txt | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/Documentation/config/merge.txt b/Documentation/config/merge.txt\nindex cb2ed58907..6b66c83eab 100644\n--- a/Documentation/config/merge.txt\n+++ b/Documentation/config/merge.txt\n@@ -14,7 +14,7 @@ merge.defaultToUpstream::\n \tbranches at the remote named by `branch..remote`\n \tare consulted, and then they are mapped via `remote..fetch`\n \tto their corresponding remote-tracking branches, and the tips of\n-\tthese tracking branches are merged.\n+\tthese tracking branches are merged. Defaults to true.\n \n merge.ff::\n \tBy default, Git does not create an extra merge commit when merging\n-- \n2.32.0.2.g41be0a4e50\n\n"},{"id":"426702","messageId":"xmqqy2blorn0.fsf@gitster.g","threadId":"55877","inReplyTo":"20210608015807.906101-1-felipe.contreras@gmail.com","subject":"Re: [PATCH] doc: merge: mention default of defaulttoupstream","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-06-08T05:24:35Z","receivedAt":"2021-06-08T05:24:39Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> Commit a01f7f2ba0 (merge: enable defaulttoupstream by default,\n> 2014-04-20) forgot to mention the new default in the configuration\n> documentation.\n>\n> Signed-off-by: Felipe Contreras \n> ---\n> Documentation/config/merge.txt | 2 +-\n> 1 file changed, 1 insertion(+), 1 deletion(-)\n>\n> diff --git a/Documentation/config/merge.txt b/Documentation/config/merge.txt\n> index cb2ed58907..6b66c83eab 100644\n> --- a/Documentation/config/merge.txt\n> +++ b/Documentation/config/merge.txt\n> @@ -14,7 +14,7 @@ merge.defaultToUpstream::\n> \tbranches at the remote named by `branch..remote`\n> \tare consulted, and then they are mapped via `remote..fetch`\n> \tto their corresponding remote-tracking branches, and the tips of\n> -\tthese tracking branches are merged.\n> +\tthese tracking branches are merged. Defaults to true.\n\nThat's definititely an improvement.\n\nWill queue.\n\nBy the way, is the convoluted description around remote-tracking\nbranches still understandable to those who often work on a branch\nforked from another local branch, or would readers be helped if we\nhad a two separate descriptions (one forking from remote and the\nother forking locally)? This is a side question as the answer does\nnot change the validity of this patch at all.\n\nThanks.\n"},{"id":"426730","messageId":"60bf1c49e3f89_1a2cb92082b@natae.notmuch","threadId":"55877","inReplyTo":"xmqqy2blorn0.fsf@gitster.g","subject":"Re: [PATCH] doc: merge: mention default of defaulttoupstream","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-06-08T07:29:13Z","receivedAt":"2021-06-08T07:29:18Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Felipe Contreras writes:\n> \n> > Commit a01f7f2ba0 (merge: enable defaulttoupstream by default,\n> > 2014-04-20) forgot to mention the new default in the configuration\n> > documentation.\n> >\n> > Signed-off-by: Felipe Contreras \n> > ---\n> > Documentation/config/merge.txt | 2 +-\n> > 1 file changed, 1 insertion(+), 1 deletion(-)\n> >\n> > diff --git a/Documentation/config/merge.txt b/Documentation/config/merge.txt\n> > index cb2ed58907..6b66c83eab 100644\n> > --- a/Documentation/config/merge.txt\n> > +++ b/Documentation/config/merge.txt\n> > @@ -14,7 +14,7 @@ merge.defaultToUpstream::\n> > \tbranches at the remote named by `branch..remote`\n> > \tare consulted, and then they are mapped via `remote..fetch`\n> > \tto their corresponding remote-tracking branches, and the tips of\n> > -\tthese tracking branches are merged.\n> > +\tthese tracking branches are merged. Defaults to true.\n> \n> That's definititely an improvement.\n> \n> Will queue.\n> \n> By the way, is the convoluted description around remote-tracking\n> branches still understandable to those who often work on a branch\n> forked from another local branch, or would readers be helped if we\n> had a two separate descriptions (one forking from remote and the\n> other forking locally)?\n\nI don't think there's any fundamental difference between origin/master,\nand master. In both cases setting upstream to that simply means \"I want\n`git rebase` to use this by default\".\n\nThere is a separate question of where you should fetch from when\nupstream is 'master' but that's another topic.\n\n\nWhat does require explanation is the triangular workflow. Separating\ndescriptions for a triangular worflow, and a two-way workflow might make\nsense.\n\n-- \nFelipe Contreras\n"}]}