{"thread":{"id":"56136","subject":"[PATCH v2] pull: introduce --merge option","startedAt":"2021-07-21T13:47:49Z","lastAt":"2021-07-28T19:25:51Z","messageCount":13,"participants":["Felipe Contreras","Linus Torvalds","Junio C Hamano","Alex Henrie","Matthias Baumgarten"],"isPatch":true,"patchVersion":2,"patchTotal":null},"messages":[{"id":"430772","messageId":"20210721134650.1866387-1-felipe.contreras@gmail.com","threadId":"56136","inReplyTo":null,"subject":"[PATCH v2] pull: introduce --merge option","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-07-21T13:46:50Z","receivedAt":"2021-07-21T13:47:49Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Users need to specify if they want to either --merge or --rebase, but\nunfortunately the former is missing.\n\nIn many discussions regarding `git pull` --merge is often mentioned, but\nfor one reason or another the patches have not been merged.\n\nLet's just go ahead and do it.\n\nNow we can update the default warning to say --merge instead of the\nnon-intuitive --no-rebase.\n\nSigned-off-by: Felipe Contreras \n---\n\nSince v1 I've removed any hint of deprecation (even though we obviously\nwant to do that), and added an actual test (I don't seem to find a\nsimialr one for --no-rebase).\n\nRange-diff against v1:\n1: 80d7866599 < -: ---------- pull: introduce --merge option\n-: ---------- > 1: 5969fc4455 pull: introduce --merge option\n\n Documentation/git-pull.txt | 6 ++++++\n builtin/pull.c | 4 +++-\n t/t5520-pull.sh | 7 +++++++\n 3 files changed, 16 insertions(+), 1 deletion(-)\n\ndiff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt\nindex 5c3fb67c01..c7a1f676cc 100644\n--- a/Documentation/git-pull.txt\n+++ b/Documentation/git-pull.txt\n@@ -134,6 +134,12 @@ unless you have read linkgit:git-rebase[1] carefully.\n --no-rebase::\n \tOverride earlier --rebase.\n \n+-m::\n+--merge::\n+\tDo a merge.\n++\n+Alias for --no-rebase.\n+\n Options related to fetching\n ~~~~~~~~~~~~~~~~~~~~~~~~~~~\n \ndiff --git a/builtin/pull.c b/builtin/pull.c\nindex 3e13f81084..0d76b54186 100644\n--- a/builtin/pull.c\n+++ b/builtin/pull.c\n@@ -129,6 +129,8 @@ static struct option pull_options[] = {\n \t\t\"(false|true|merges|preserve|interactive)\",\n \t\tN_(\"incorporate changes by rebasing rather than merging\"),\n \t\tPARSE_OPT_OPTARG, parse_opt_rebase),\n+\tOPT_SET_INT('m', \"merge\", &opt_rebase,\n+\t\tN_(\"incorporate changes by merging\"), REBASE_FALSE),\n \tOPT_PASSTHRU('n', NULL, &opt_diffstat, NULL,\n \t\tN_(\"do not show a diffstat at the end of the merge\"),\n \t\tPARSE_OPT_NOARG | PARSE_OPT_NONEG),\n@@ -936,7 +938,7 @@ static void show_advice_pull_non_ff(void)\n \t\t \" git config pull.ff only # fast-forward only\\n\"\n \t\t \"\\n\"\n \t\t \"You can replace \\\"git config\\\" with \\\"git config --global\\\" to set a default\\n\"\n-\t\t \"preference for all repositories. You can also pass --rebase, --no-rebase,\\n\"\n+\t\t \"preference for all repositories. You can also pass --rebase, --merge,\\n\"\n \t\t \"or --ff-only on the command line to override the configured default per\\n\"\n \t\t \"invocation.\\n\"));\n }\ndiff --git a/t/t5520-pull.sh b/t/t5520-pull.sh\nindex e2c0c51022..f299a82405 100755\n--- a/t/t5520-pull.sh\n+++ b/t/t5520-pull.sh\n@@ -452,6 +452,13 @@ test_expect_success 'pull.rebase' '\n \ttest_cmp expect actual\n '\n \n+test_expect_success 'pull.rebase with --merge' '\n+\tgit reset --hard before-rebase &&\n+\ttest_config pull.rebase true &&\n+\tgit pull --merge . copy &&\n+\ttest_cmp_rev HEAD^2 copy\n+'\n+\n test_expect_success 'pull --autostash & pull.rebase=true' '\n \ttest_config pull.rebase true &&\n \ttest_pull_autostash 1 --autostash\n-- \n2.32.0.40.gb9b36f9b52\n\n"},{"id":"430777","messageId":"CAHk-=whf-9kNV3y5G-VVA2K5EZCnvv94paAEj6p=i2R4RM2emQ@mail.gmail.com","threadId":"56136","inReplyTo":"20210721134650.1866387-1-felipe.contreras@gmail.com","subject":"Re: [PATCH v2] pull: introduce --merge option","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2021-07-21T17:06:11Z","receivedAt":"2021-07-21T17:06:34Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"On Wed, Jul 21, 2021 at 6:47 AM Felipe Contreras\n wrote:\n>\n> Users need to specify if they want to either --merge or --rebase, but\n> unfortunately the former is missing.\n\nAck. I think it's just historical, because long long ago it used to be\nthat 'git pull' always merged unless told otherwise with --rebase.\n\n Linus\n"},{"id":"430778","messageId":"xmqqeebregns.fsf@gitster.g","threadId":"56136","inReplyTo":"CAHk-=whf-9kNV3y5G-VVA2K5EZCnvv94paAEj6p=i2R4RM2emQ@mail.gmail.com","subject":"Re: [PATCH v2] pull: introduce --merge option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-07-21T17:11:03Z","receivedAt":"2021-07-21T17:11:10Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> On Wed, Jul 21, 2021 at 6:47 AM Felipe Contreras\n> wrote:\n>>\n>> Users need to specify if they want to either --merge or --rebase, but\n>> unfortunately the former is missing.\n>\n> Ack. I think it's just historical, because long long ago it used to be\n> that 'git pull' always merged unless told otherwise with --rebase.\n\nThe \"--no-rebase\" option, which is documented as a synonym for\n\"--rebase=false\", has been there, but the implementation is buggy in\nsome corner cases, which has been worked on recently in a separate\nthread. I do not think it is too bad to add \"--merge\" as yet\nanother synonym for \"--rebase=false\".\n\n"},{"id":"431163","messageId":"CAMMLpeTL92cDmMHsE3iuhHQrVjwLFWHxE0CwD+uDBoPGAQCrkg@mail.gmail.com","threadId":"56136","inReplyTo":"xmqqeebregns.fsf@gitster.g","subject":"Re: [PATCH v2] pull: introduce --merge option","fromName":"Alex Henrie","fromEmail":"alexhenrie24@gmail.com","sentAt":"2021-07-26T04:06:46Z","receivedAt":"2021-07-26T04:07:01Z","isPatch":true,"sender":{"key":"alexhenrie24@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5951993?v=4"},"body":"On Wed, Jul 21, 2021 at 11:11 AM Junio C Hamano wrote:\n>\n> The \"--no-rebase\" option, which is documented as a synonym for\n> \"--rebase=false\", has been there, but the implementation is buggy in\n> some corner cases, which has been worked on recently in a separate\n> thread. I do not think it is too bad to add \"--merge\" as yet\n> another synonym for \"--rebase=false\".\n\nIt's convenient to have the one-letter option `git pull -r` to\noverride the configuration and do a rebase. I'd really like to have a\nsimilar one-letter option `git pull -m` to override the configuration\nand do a merge. That would also alleviate a lot of the desire for a\nseparate `git update` (i.e. \"fetch and rebase\") command.\n\nJunio, would you be willing to accept adding -m without adding --merge also?\n\n-Alex\n"},{"id":"431284","messageId":"60ff75c0e29b6_2d1d20889@natae.notmuch","threadId":"56136","inReplyTo":"CAMMLpeTL92cDmMHsE3iuhHQrVjwLFWHxE0CwD+uDBoPGAQCrkg@mail.gmail.com","subject":"Re: [PATCH v2] pull: introduce --merge option","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-07-27T02:56:00Z","receivedAt":"2021-07-27T02:56:06Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Alex Henrie wrote:\n> On Wed, Jul 21, 2021 at 11:11 AM Junio C Hamano wrote:\n> >\n> > The \"--no-rebase\" option, which is documented as a synonym for\n> > \"--rebase=false\", has been there, but the implementation is buggy in\n> > some corner cases, which has been worked on recently in a separate\n> > thread. I do not think it is too bad to add \"--merge\" as yet\n> > another synonym for \"--rebase=false\".\n> \n> It's convenient to have the one-letter option `git pull -r` to\n> override the configuration and do a rebase. I'd really like to have a\n> similar one-letter option `git pull -m` to override the configuration\n> and do a merge. That would also alleviate a lot of the desire for a\n> separate `git update` (i.e. \"fetch and rebase\") command.\n\nMy proposed `git update` is not \"fetch and rebase\", but fetch and\nfast-forward.\n\nMorevoer, `git pull -m` would still merge with the wrong order of the\nparents. On the other hand `git update --merge` would merge them with\nthe correct order.\n\nI'm not sure what -m would alleviate.\n\n-- \nFelipe Contreras\n"},{"id":"431288","messageId":"60ffa856a332d_7d082086f@natae.notmuch","threadId":"56136","inReplyTo":"xmqqeebregns.fsf@gitster.g","subject":"Re: [PATCH v2] pull: introduce --merge option","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-07-27T06:31:50Z","receivedAt":"2021-07-27T06:31:55Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Linus Torvalds writes:\n> \n> > On Wed, Jul 21, 2021 at 6:47 AM Felipe Contreras\n> > wrote:\n> >>\n> >> Users need to specify if they want to either --merge or --rebase, but\n> >> unfortunately the former is missing.\n> >\n> > Ack. I think it's just historical, because long long ago it used to be\n> > that 'git pull' always merged unless told otherwise with --rebase.\n> \n> The \"--no-rebase\" option, which is documented as a synonym for\n> \"--rebase=false\", has been there, but the implementation is buggy in\n> some corner cases, which has been worked on recently in a separate\n> thread. I do not think it is too bad to add \"--merge\" as yet\n> another synonym for \"--rebase=false\".\n\nAny particular reason why this is not a topic? [1]\n\n[1] https://lore.kernel.org/git/xmqq35s0fj9o.fsf@gitster.g/\n\n-- \nFelipe Contreras\n"},{"id":"431293","messageId":"xmqqwnpcdu1w.fsf@gitster.g","threadId":"56136","inReplyTo":"CAMMLpeTL92cDmMHsE3iuhHQrVjwLFWHxE0CwD+uDBoPGAQCrkg@mail.gmail.com","subject":"Re: [PATCH v2] pull: introduce --merge option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-07-27T08:45:15Z","receivedAt":"2021-07-27T08:45:21Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Alex Henrie writes:\n\n> Junio, would you be willing to accept adding -m without adding --merge also?\n\nMy gut feeling is that \"-m\" without \"--merge\" in the context of\n\"pull\" is extremely unlikely to fly well.\n\nAs \"git pull\" is a \"git fetch\" followed by a \"git merge\" (or \"git\nrebase\"), it takes the union of common command line options from\nboth phases, and \"git merge\" takes \"-m 'message'\" which is an option\nfairly familiar to users (since it comes from \"git commit\"). Even\nif we are never going to pass \"-m message\" from \"git pull\" down to\nunderlying \"git merge\", squatting on short and common \"-m\" would be\na bad idea.\n"},{"id":"431313","messageId":"CAMMLpeQ-Qpct4TX__KVuCyjbgxtB49qTMRHYc9R9-o0cRu4MuA@mail.gmail.com","threadId":"56136","inReplyTo":"xmqqwnpcdu1w.fsf@gitster.g","subject":"Re: [PATCH v2] pull: introduce --merge option","fromName":"Alex Henrie","fromEmail":"alexhenrie24@gmail.com","sentAt":"2021-07-27T15:52:14Z","receivedAt":"2021-07-27T15:52:30Z","isPatch":true,"sender":{"key":"alexhenrie24@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5951993?v=4"},"body":"On Tue, Jul 27, 2021 at 2:45 AM Junio C Hamano wrote:\n>\n> Alex Henrie writes:\n>\n> > Junio, would you be willing to accept adding -m without adding --merge also?\n>\n> My gut feeling is that \"-m\" without \"--merge\" in the context of\n> \"pull\" is extremely unlikely to fly well.\n>\n> As \"git pull\" is a \"git fetch\" followed by a \"git merge\" (or \"git\n> rebase\"), it takes the union of common command line options from\n> both phases, and \"git merge\" takes \"-m 'message'\" which is an option\n> fairly familiar to users (since it comes from \"git commit\"). Even\n> if we are never going to pass \"-m message\" from \"git pull\" down to\n> underlying \"git merge\", squatting on short and common \"-m\" would be\n> a bad idea.\n\nThanks for the explanation. I forgot that \"-m\" usually means\n\"message\". That does seem like a good reason to not use \"-m\" for\n\"merge\".\n\n-Alex\n"},{"id":"431316","messageId":"610038c0e1056_8fd52084a@natae.notmuch","threadId":"56136","inReplyTo":"CAMMLpeQ-Qpct4TX__KVuCyjbgxtB49qTMRHYc9R9-o0cRu4MuA@mail.gmail.com","subject":"Re: [PATCH v2] pull: introduce --merge option","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-07-27T16:48:00Z","receivedAt":"2021-07-27T16:48:06Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Alex Henrie wrote:\n> On Tue, Jul 27, 2021 at 2:45 AM Junio C Hamano wrote:\n> >\n> > Alex Henrie writes:\n> >\n> > > Junio, would you be willing to accept adding -m without adding --merge also?\n> >\n> > My gut feeling is that \"-m\" without \"--merge\" in the context of\n> > \"pull\" is extremely unlikely to fly well.\n> >\n> > As \"git pull\" is a \"git fetch\" followed by a \"git merge\" (or \"git\n> > rebase\"), it takes the union of common command line options from\n> > both phases, and \"git merge\" takes \"-m 'message'\" which is an option\n> > fairly familiar to users (since it comes from \"git commit\"). Even\n> > if we are never going to pass \"-m message\" from \"git pull\" down to\n> > underlying \"git merge\", squatting on short and common \"-m\" would be\n> > a bad idea.\n> \n> Thanks for the explanation. I forgot that \"-m\" usually means\n> \"message\". That does seem like a good reason to not use \"-m\" for\n> \"merge\".\n\nIt means --merge plenty of times:\n\n * git restore -m\n * git checkout -m\n * git rebase -m\n * git diff -m\n * git read-tree -m\n * git diff-tree -m\n\n-- \nFelipe Contreras\n"},{"id":"431388","messageId":"9e8f1c87-cd08-e1a2-fd5d-713cb0590049@aixigo.com","threadId":"56136","inReplyTo":"610038c0e1056_8fd52084a@natae.notmuch","subject":"Re: [PATCH v2] pull: introduce --merge option","fromName":"Matthias Baumgarten","fromEmail":"matthias.baumgarten@aixigo.com","sentAt":"2021-07-28T07:44:20Z","receivedAt":"2021-07-28T07:44:33Z","isPatch":true,"sender":{"key":"matthias.baumgarten@aixigo.com","avatar":null},"body":"On 7/27/21 6:48 PM, Felipe Contreras wrote:\n> Alex Henrie wrote:\n>> On Tue, Jul 27, 2021 at 2:45 AM Junio C Hamano wrote:\n>>>\n>>> Alex Henrie writes:\n>>>\n>>>> Junio, would you be willing to accept adding -m without adding --merge also?\n>>>\n>>> My gut feeling is that \"-m\" without \"--merge\" in the context of\n>>> \"pull\" is extremely unlikely to fly well.\n>>>\n>>> As \"git pull\" is a \"git fetch\" followed by a \"git merge\" (or \"git\n>>> rebase\"), it takes the union of common command line options from\n>>> both phases, and \"git merge\" takes \"-m 'message'\" which is an option\n>>> fairly familiar to users (since it comes from \"git commit\"). Even\n>>> if we are never going to pass \"-m message\" from \"git pull\" down to\n>>> underlying \"git merge\", squatting on short and common \"-m\" would be\n>>> a bad idea.\n>>\n>> Thanks for the explanation. I forgot that \"-m\" usually means\n>> \"message\". That does seem like a good reason to not use \"-m\" for\n>> \"merge\".\n> \n> It means --merge plenty of times:\n> \n> * git restore -m\n> * git checkout -m\n> * git rebase -m\n> * git diff -m\n> * git read-tree -m\n> * git diff-tree -m\n\nAdd to Felipes list:\n\n * git switch -m\n\nand maybe git cherry-pick -m where -m does not mean \"merge\" itself but \nis used to determine the parent of the merge (when picking merge \ncommits) to base on.\n\nOther examples of where -m has different meaning than merge:\n\n * git am -m (message-id)\n * git branch -m (move branch)\n\nI would rephrase the question as to what would I expect `git pull -m` to \ndo, if I had never heard of it before. In the case of fast-forwarding \nand rebasing trying to add a merge commit message with -m would not even \nmake sense. Only in the case of trying to create a merge commit by \nissuing git pull this would make sense. So if we could agree on that \nbeing not the most used scenario, I think -m would be a great short \noption for --merge.\n\n-- \naixigo AG\nKarl-Friedrich-Str. 68, 52072 Aachen, Germany\nphone: +49 (0)241 559709-390, fax: +49 (0)241 559709-99\nemail: matthias.baumgarten@aixigo.com\nweb: https://www.aixigo.com\nDistrict Court Aachen – HRB 8057\nBoard: Christian Friedrich, Tobias Haustein\nChairman of the Supervisory Board: Dr. Roland Schlager\n"},{"id":"431407","messageId":"xmqqv94u9x2l.fsf@gitster.g","threadId":"56136","inReplyTo":"9e8f1c87-cd08-e1a2-fd5d-713cb0590049@aixigo.com","subject":"Re: [PATCH v2] pull: introduce --merge option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-07-28T17:18:10Z","receivedAt":"2021-07-28T17:18:13Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthias Baumgarten writes:\n\n> Add to Felipes list:\n>\n> * git switch -m\n>\n> and maybe git cherry-pick -m where -m does not mean \"merge\" itself but\n> is used to determine the parent of the merge (when picking merge \n> commits) to base on.\n>\n> Other examples of where -m has different meaning than merge:\n>\n> * git am -m (message-id)\n> * git branch -m (move branch)\n>\n> I would rephrase the question as to what would I expect `git pull -m`\n> to do, if I had never heard of it before. In the case of\n> fast-forwarding and rebasing trying to add a merge commit message with\n> -m would not even make sense. Only in the case of trying to create a\n> merge commit by issuing git pull this would make sense. So if we could\n> agree on that being not the most used scenario, I think -m would be a\n> great short option for --merge.\n\nI am afraid that you are misinterpreting what I said, comparing\napples and oranges, and drawing a wrong conclusion.\n\nWhen I said \"-m\" would not fly well as a short-hand for \"--merge\" in\nthe context of \"pull\", I didn't mean \"nobody would think 'm' stands\nfor 'merge'\", and I didn't mean \"more people would think 'm' stands\nfor 'message' more than 'merge'\". The reason why I find it\nproblematic is because it can be ambiguous.\n\nWhen we step back and think about your \"switch -m\" and its synonym\n\"checkout -m\", we realize that these commands fundamentally never\ntake \"--message\", as there is no place to record such a message\n(they do not create a commit after all), after they switch to a\ndifferent branch while carrying the local modification forward by\nperforming a (possibly conflicting) content-level merge. That is\nwhy we can give their \"merge\" operation a short-and-sweet \"m\"\nwithout confusing our users. So contrasting \"switch\" having \"-m\"\nthat means \"merge\" with \"pull\" that can conceivably take both\n\"merge\" and \"message\" is not a comparison you can draw useful\nconclusion from.\n\n\n\n"},{"id":"431415","messageId":"e5952eea-61f2-1beb-64a2-1a077c57f0e6@aixigo.com","threadId":"56136","inReplyTo":"xmqqv94u9x2l.fsf@gitster.g","subject":"Re: [PATCH v2] pull: introduce --merge option","fromName":"Matthias Baumgarten","fromEmail":"matthias.baumgarten@aixigo.com","sentAt":"2021-07-28T18:18:07Z","receivedAt":"2021-07-28T18:18:19Z","isPatch":true,"sender":{"key":"matthias.baumgarten@aixigo.com","avatar":null},"body":"On 7/28/21 7:18 PM, Junio C Hamano wrote:\n> I am afraid that you are misinterpreting what I said, comparing\n> apples and oranges, and drawing a wrong conclusion >\n> When I said \"-m\" would not fly well as a short-hand for \"--merge\" in\n> the context of \"pull\", I didn't mean \"nobody would think 'm' stands\n> for 'merge'\", and I didn't mean \"more people would think 'm' stands\n> for 'message' more than 'merge'\". The reason why I find it\n> problematic is because it can be ambiguous >\n> When we step back and think about your \"switch -m\" and its synonym\n> \"checkout -m\", we realize that these commands fundamentally never\n> take \"--message\", as there is no place to record such a message\n> (they do not create a commit after all), after they switch to a\n> different branch while carrying the local modification forward by\n> performing a (possibly conflicting) content-level merge. That is\n> why we can give their \"merge\" operation a short-and-sweet \"m\"\n> without confusing our users. So contrasting \"switch\" having \"-m\"\n> that means \"merge\" with \"pull\" that can conceivably take both\n> \"merge\" and \"message\" is not a comparison you can draw useful\n> conclusion from.\nI must confess that this comparison is indeed not a valid one. Maybe -m \nisn't as great as I thought it was.\n\n-- \naixigo AG\nKarl-Friedrich-Str. 68, 52072 Aachen, Germany\nphone: +49 (0)241 559709-390, fax: +49 (0)241 559709-99\nemail: matthias.baumgarten@aixigo.com\nweb: https://www.aixigo.com\nDistrict Court Aachen – HRB 8057\nBoard: Christian Friedrich, Tobias Haustein\nChairman of the Supervisory Board: Dr. Roland Schlager\n"},{"id":"431418","messageId":"6101af37cabc_41362084d@natae.notmuch","threadId":"56136","inReplyTo":"xmqqv94u9x2l.fsf@gitster.g","subject":"Re: [PATCH v2] pull: introduce --merge option","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-07-28T19:25:43Z","receivedAt":"2021-07-28T19:25:51Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Matthias Baumgarten writes:\n> \n> > Add to Felipes list:\n> >\n> > * git switch -m\n> >\n> > and maybe git cherry-pick -m where -m does not mean \"merge\" itself but\n> > is used to determine the parent of the merge (when picking merge \n> > commits) to base on.\n> >\n> > Other examples of where -m has different meaning than merge:\n> >\n> > * git am -m (message-id)\n> > * git branch -m (move branch)\n> >\n> > I would rephrase the question as to what would I expect `git pull -m`\n> > to do, if I had never heard of it before. In the case of\n> > fast-forwarding and rebasing trying to add a merge commit message with\n> > -m would not even make sense. Only in the case of trying to create a\n> > merge commit by issuing git pull this would make sense. So if we could\n> > agree on that being not the most used scenario, I think -m would be a\n> > great short option for --merge.\n> \n> I am afraid that you are misinterpreting what I said, comparing\n> apples and oranges, and drawing a wrong conclusion.\n> \n> When I said \"-m\" would not fly well as a short-hand for \"--merge\" in\n> the context of \"pull\", I didn't mean \"nobody would think 'm' stands\n> for 'merge'\", and I didn't mean \"more people would think 'm' stands\n> for 'message' more than 'merge'\". The reason why I find it\n> problematic is because it can be ambiguous.\n\nThe question shouldn't be \"can it be ambiguous?\", the question should be\n\"is it ambiguous?\".\n\nThe *main* purpose of `git pull` is to integrate remote changes, and the\nfirst question asked is \"how?\".\n\n git pull --merge|-m\n git pull --rebase|-r\n\nSo I don't see why it is ambiguous.\n\nThe fact that a tiny minority of users might find a command (any command)\nambiguous is not valid reason for its inexistence. By that rationale\n`git pull` shouldn't exist at all, because many find it ambiguous that\nit's not the symmetric command opposed to `git push`.\n\nThe vast majority of users shouldn't suffer because of the confusion of\na tiny few. The tiny few can simply look at the documentation.\n\n-- \nFelipe Contreras\n"}]}