{"thread":{"id":"54697","subject":"[PATCH v7 0/1] Reject non-ff pulls by default","startedAt":"2020-11-23T22:46:47Z","lastAt":"2020-11-24T03:45:29Z","messageCount":11,"participants":["Felipe Contreras","Alex Henrie","Junio C Hamano","Raymond E. Pasco","Jeff King"],"isPatch":true,"patchVersion":7,"patchTotal":1},"messages":[{"id":"410586","messageId":"20201123224621.2573159-1-felipe.contreras@gmail.com","threadId":"54697","inReplyTo":null,"subject":"[PATCH v7 0/1] Reject non-ff pulls by default","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-11-23T22:46:20Z","receivedAt":"2020-11-23T22:46:47Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"This is an attempt to revive the old patch series [1], except the only thing it's doing is the\nimportant change: adding the option to reject non-ff pulls.\n\nFollowing this patch the next one should add a new default mode that warns instead of fail, and the\nnext one change the default to ff-only.\n\nThis leaves the interface in an inconsistent state, IMO, since I believe these should work:\n\n * git pull --rebase\n * git pull --merge\n * git -c pull.mode=rebase pull\n * git -c pull.mode=merge pull\n * git -c pull.mode=ff-only pull\n\nBut that can be fixed later.\n\nCheers.\n\n[1] https://lore.kernel.org/git/1398988808-29678-1-git-send-email-felipe.contreras@gmail.com/\n\n\nFelipe Contreras (1):\n pull: add ff-only option\n\n Documentation/config/branch.txt | 2 ++\n Documentation/config/pull.txt | 2 ++\n builtin/pull.c | 6 +++++-\n rebase.c | 2 ++\n rebase.h | 3 ++-\n t/t5520-pull.sh | 36 +++++++++++++++++++++++++++++++++\n 6 files changed, 49 insertions(+), 2 deletions(-)\n\n-- \n2.29.2\n\n"},{"id":"410587","messageId":"20201123224621.2573159-2-felipe.contreras@gmail.com","threadId":"54697","inReplyTo":"20201123224621.2573159-1-felipe.contreras@gmail.com","subject":"[PATCH v7 1/1] pull: add ff-only option","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-11-23T22:46:21Z","receivedAt":"2020-11-23T22:46:47Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"It is very typical for Git newcomers to inadvertently create merges and\nworse; inadvertently pushing them. This is one of the reasons many\nexperienced users prefer to avoid 'git pull', and recommend newcomers to\navoid it as well.\n\nTo avoid these problems, and keep 'git pull' useful, it has been\nsuggested that 'git pull' barfs by default if the merge is\nnon-fast-forward, which unfortunately would break backwards\ncompatibility.\n\nThis patch leaves everything in place to enable this new mode, but it\nonly gets enabled if the user specifically configures it;\n\n pull.rebase = ff-only.\n\nLater on this mode can be enabled by default.\n\nFor the full discussion you can read:\n\nhttps://lore.kernel.org/git/5363BB9F.40102@xiplink.com/\n\nSigned-off-by: Felipe Contreras \n---\n Documentation/config/branch.txt | 2 ++\n Documentation/config/pull.txt | 2 ++\n builtin/pull.c | 6 +++++-\n rebase.c | 2 ++\n rebase.h | 3 ++-\n t/t5520-pull.sh | 36 +++++++++++++++++++++++++++++++++\n 6 files changed, 49 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/config/branch.txt b/Documentation/config/branch.txt\nindex cc5f3249fc..715987c759 100644\n--- a/Documentation/config/branch.txt\n+++ b/Documentation/config/branch.txt\n@@ -81,6 +81,8 @@ branch..rebase::\n \t\"git pull\" is run. See \"pull.rebase\" for doing this in a non\n \tbranch-specific manner.\n +\n+When `ff-only` (or just 'f'), the rebase will only succeed if it's fast-forward.\n++\n When `merges` (or just 'm'), pass the `--rebase-merges` option to 'git rebase'\n so that the local merge commits are included in the rebase (see\n linkgit:git-rebase[1] for details).\ndiff --git a/Documentation/config/pull.txt b/Documentation/config/pull.txt\nindex 5404830609..060bacc63c 100644\n--- a/Documentation/config/pull.txt\n+++ b/Documentation/config/pull.txt\n@@ -14,6 +14,8 @@ pull.rebase::\n \tpull\" is run. See \"branch..rebase\" for setting this on a\n \tper-branch basis.\n +\n+When `ff-only` (or just 'f'), the rebase will only succeed if it's fast-forward.\n++\n When `merges` (or just 'm'), pass the `--rebase-merges` option to 'git rebase'\n so that the local merge commits are included in the rebase (see\n linkgit:git-rebase[1] for details).\ndiff --git a/builtin/pull.c b/builtin/pull.c\nindex 17aa63cd35..ba2777c401 100644\n--- a/builtin/pull.c\n+++ b/builtin/pull.c\n@@ -1033,8 +1033,12 @@ int cmd_pull(int argc, const char **argv, const char *prefix)\n \t\t\t}\n \t\t\tfree_commit_list(list);\n \t\t}\n-\t\tif (!ran_ff)\n+\t\tif (!ran_ff) {\n+\t\t\tif (opt_rebase == REBASE_FF_ONLY)\n+\t\t\t\tdie(_(\"The pull was not fast-forward, please either merge or rebase.\\n\"\n+\t\t\t\t\t\"If unsure, run 'git pull --merge'.\"));\n \t\t\tret = run_rebase(&curr_head, merge_heads.oid, &rebase_fork_point);\n+\t\t}\n \n \t\tif (!ret && (recurse_submodules == RECURSE_SUBMODULES_ON ||\n \t\t\t recurse_submodules == RECURSE_SUBMODULES_ON_DEMAND))\ndiff --git a/rebase.c b/rebase.c\nindex f8137d859b..eba1253552 100644\n--- a/rebase.c\n+++ b/rebase.c\n@@ -20,6 +20,8 @@ enum rebase_type rebase_parse_value(const char *value)\n \t\treturn REBASE_FALSE;\n \telse if (v > 0)\n \t\treturn REBASE_TRUE;\n+\telse if (!strcmp(value, \"ff-only\") || !strcmp(value, \"f\"))\n+\t\treturn REBASE_FF_ONLY;\n \telse if (!strcmp(value, \"preserve\") || !strcmp(value, \"p\"))\n \t\treturn REBASE_PRESERVE;\n \telse if (!strcmp(value, \"merges\") || !strcmp(value, \"m\"))\ndiff --git a/rebase.h b/rebase.h\nindex cc723d4748..127febeb7c 100644\n--- a/rebase.h\n+++ b/rebase.h\n@@ -7,7 +7,8 @@ enum rebase_type {\n \tREBASE_TRUE,\n \tREBASE_PRESERVE,\n \tREBASE_MERGES,\n-\tREBASE_INTERACTIVE\n+\tREBASE_INTERACTIVE,\n+\tREBASE_FF_ONLY\n };\n \n enum rebase_type rebase_parse_value(const char *value);\ndiff --git a/t/t5520-pull.sh b/t/t5520-pull.sh\nindex 9fae07cdfa..d96bdc90cc 100755\n--- a/t/t5520-pull.sh\n+++ b/t/t5520-pull.sh\n@@ -819,4 +819,40 @@ test_expect_success 'git pull --rebase against local branch' '\n \ttest_cmp expect file2\n '\n \n+test_expect_success 'git pull fast-forward (ff-only)' '\n+\ttest_when_finished \"git checkout master && git branch -D other test\" &&\n+\ttest_config pull.rebase ff-only &&\n+\tgit checkout -b other master &&\n+\t>new &&\n+\tgit add new &&\n+\tgit commit -m new &&\n+\tgit checkout -b test -t other &&\n+\tgit reset --hard master &&\n+\tgit pull\n+'\n+\n+test_expect_success 'git pull non-fast-forward (ff-only)' '\n+\ttest_when_finished \"git checkout master && git branch -D other test\" &&\n+\ttest_config pull.rebase ff-only &&\n+\tgit checkout -b other master^ &&\n+\t>new &&\n+\tgit add new &&\n+\tgit commit -m new &&\n+\tgit checkout -b test -t other &&\n+\tgit reset --hard master &&\n+\ttest_must_fail git pull\n+'\n+\n+test_expect_success 'git pull non-fast-forward with merge (ff-only)' '\n+\ttest_when_finished \"git checkout master && git branch -D other test\" &&\n+\ttest_config pull.rebase ff-only &&\n+\tgit checkout -b other master^ &&\n+\t>new &&\n+\tgit add new &&\n+\tgit commit -m new &&\n+\tgit checkout -b test -t other &&\n+\tgit reset --hard master &&\n+\tgit pull --no-rebase\n+'\n+\n test_done\n-- \n2.29.2\n\n"},{"id":"410591","messageId":"CAMP44s2FRZUvUy+F3banxd9MEdL=RMqEdJL3JLYEGDQkOz3vNA@mail.gmail.com","threadId":"54697","inReplyTo":"20201123224621.2573159-2-felipe.contreras@gmail.com","subject":"Re: [PATCH v7 1/1] pull: add ff-only option","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-11-23T23:02:42Z","receivedAt":"2020-11-23T23:03:17Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Mon, Nov 23, 2020 at 4:46 PM Felipe Contreras\n wrote:\n>\n> It is very typical for Git newcomers to inadvertently create merges and\n> worse; inadvertently pushing them. This is one of the reasons many\n> experienced users prefer to avoid 'git pull', and recommend newcomers to\n> avoid it as well.\n>\n> To avoid these problems, and keep 'git pull' useful, it has been\n> suggested that 'git pull' barfs by default if the merge is\n> non-fast-forward, which unfortunately would break backwards\n> compatibility.\n>\n> This patch leaves everything in place to enable this new mode, but it\n> only gets enabled if the user specifically configures it;\n>\n> pull.rebase = ff-only.\n>\n> Later on this mode can be enabled by default.\n>\n> For the full discussion you can read:\n>\n> https://lore.kernel.org/git/5363BB9F.40102@xiplink.com/\n\nNote: Philip Oakley's address was wrong (fixed now).\n\n-- \nFelipe Contreras\n"},{"id":"410598","messageId":"CAMMLpeR8_fshsaqSF6idOY-KyFw2+AK_5683a-7wDXhsO=iFVQ@mail.gmail.com","threadId":"54697","inReplyTo":"CAMP44s2FRZUvUy+F3banxd9MEdL=RMqEdJL3JLYEGDQkOz3vNA@mail.gmail.com","subject":"Re: [PATCH v7 1/1] pull: add ff-only option","fromName":"Alex Henrie","fromEmail":"alexhenrie24@gmail.com","sentAt":"2020-11-23T23:22:28Z","receivedAt":"2020-11-23T23:23:05Z","isPatch":true,"sender":{"key":"alexhenrie24@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5951993?v=4"},"body":"On Mon, Nov 23, 2020 at 3:46 PM Felipe Contreras\n wrote:\n>\n> This patch leaves everything in place to enable this new mode, but it\n> only gets enabled if the user specifically configures it;\n>\n> pull.rebase = ff-only.\n\nWhy not use the existing pull.ff=only option instead of adding a new one?\n\n-Alex\n"},{"id":"410601","messageId":"xmqqim9vlkdn.fsf@gitster.c.googlers.com","threadId":"54697","inReplyTo":"CAMMLpeR8_fshsaqSF6idOY-KyFw2+AK_5683a-7wDXhsO=iFVQ@mail.gmail.com","subject":"Re: [PATCH v7 1/1] pull: add ff-only option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-11-23T23:32:36Z","receivedAt":"2020-11-23T23:33:02Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Alex Henrie writes:\n\n> On Mon, Nov 23, 2020 at 3:46 PM Felipe Contreras\n> wrote:\n>>\n>> This patch leaves everything in place to enable this new mode, but it\n>> only gets enabled if the user specifically configures it;\n>>\n>> pull.rebase = ff-only.\n>\n> Why not use the existing pull.ff=only option instead of adding a new one?\n\nIf you have pull.rebase=false, \"git -c pull.ff=only pull\" would fail\nas desired upon a non-fast-forward. But if you have\npull.rebase=true, does it fail the same way (not a rhetorical\nquestion; I didn't try)? If so, I agree we do not need a new one.\n\nOtherwise, I am on two minds.\n\nHaving just a single variable would be easier to manage, so\npull.rebase=ff-only that is equivalent to pull.ff=only might be\nclaimed to be UI improvement.\n\nOn the other hand, it looks quite funny for that single variable\nthat controls the way how pull works, whether rebase or merge is\nused, is pull.REBASE.\n\n\n"},{"id":"410604","messageId":"CAMP44s3Y3BEbPM_69uxmQWiBq2CqwBo4w13M43WvU4nUQZha8g@mail.gmail.com","threadId":"54697","inReplyTo":"xmqqim9vlkdn.fsf@gitster.c.googlers.com","subject":"Re: [PATCH v7 1/1] pull: add ff-only option","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-11-23T23:51:42Z","receivedAt":"2020-11-23T23:52:16Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Mon, Nov 23, 2020 at 5:32 PM Junio C Hamano wrote:\n>\n> Alex Henrie writes:\n>\n> > On Mon, Nov 23, 2020 at 3:46 PM Felipe Contreras\n> > wrote:\n> >>\n> >> This patch leaves everything in place to enable this new mode, but it\n> >> only gets enabled if the user specifically configures it;\n> >>\n> >> pull.rebase = ff-only.\n> >\n> > Why not use the existing pull.ff=only option instead of adding a new one?\n>\n> If you have pull.rebase=false, \"git -c pull.ff=only pull\" would fail\n> as desired upon a non-fast-forward. But if you have\n> pull.rebase=true, does it fail the same way (not a rhetorical\n> question; I didn't try)? If so, I agree we do not need a new one.\n\nNo. It attempts the rebase, because whatever is set in pull.ff affects\nonly the merge mode. Also, I don't think there's any way to tell git\nrebase to fail if it's not fast-forward (not that we should attempt\nthe rebase anyway).\n\n> On the other hand, it looks quite funny for that single variable\n> that controls the way how pull works, whether rebase or merge is\n> used, is pull.REBASE.\n\nWhich is precisely why I wanted to rename it to pull.mode.\n\nIn my option git pull should have three main modes:\n\n1. fast-forward only\n2. merge\n3. rebase\n\nThe fast-forward only mode can be considered a merge, or a rebase,\ndoesn't matter.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"410606","messageId":"CAMP44s0r1vf7x-wHP-b6KQRU7mcPSZzcMRK2VqqxU_SJRDs+kg@mail.gmail.com","threadId":"54697","inReplyTo":"CAMMLpeR8_fshsaqSF6idOY-KyFw2+AK_5683a-7wDXhsO=iFVQ@mail.gmail.com","subject":"Re: [PATCH v7 1/1] pull: add ff-only option","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-11-24T00:08:17Z","receivedAt":"2020-11-24T00:08:32Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Mon, Nov 23, 2020 at 5:22 PM Alex Henrie wrote:\n>\n> On Mon, Nov 23, 2020 at 3:46 PM Felipe Contreras\n> wrote:\n> >\n> > This patch leaves everything in place to enable this new mode, but it\n> > only gets enabled if the user specifically configures it;\n> >\n> > pull.rebase = ff-only.\n>\n> Why not use the existing pull.ff=only option instead of adding a new one?\n\nBecause that option is only for the merge.\n\nI'd have no objection in refactoring this option so it's used for\nboth, but this breaks existing behavior. A user that has\n\"pull.ff=only\", and does a \"git pull --rebase\" might expect it to\nwork.\n\nMy main interest is what happens when the user has not configured\nanything, which I defined with a \"push.mode=default\", any option (e.g.\n--rebase/--merge) would override that default.\n\n-- \nFelipe Contreras\n"},{"id":"410613","messageId":"C7B2K1BLPDIO.1D6XVJIWIG3UZ@ziyou.local","threadId":"54697","inReplyTo":"CAMP44s0r1vf7x-wHP-b6KQRU7mcPSZzcMRK2VqqxU_SJRDs+kg@mail.gmail.com","subject":"Re: [PATCH v7 1/1] pull: add ff-only option","fromName":"Raymond E. Pasco","fromEmail":"ray@ameretat.dev","sentAt":"2020-11-24T00:32:07Z","receivedAt":"2020-11-24T00:59:46Z","isPatch":true,"sender":{"key":"ray@ameretat.dev","avatar":"https://avatars.githubusercontent.com/u/115765?v=4"},"body":"On Mon Nov 23, 2020 at 7:08 PM EST, Felipe Contreras wrote:\n> I'd have no objection in refactoring this option so it's used for\n> both, but this breaks existing behavior. A user that has\n> \"pull.ff=only\", and does a \"git pull --rebase\" might expect it to\n> work.\n>\n> My main interest is what happens when the user has not configured\n> anything, which I defined with a \"push.mode=default\", any option (e.g.\n> --rebase/--merge) would override that default.\n\nI feel like the parsimonious change to make is simply defaulting the\nexisting \"pull.ff\" to \"only\". I think someone who has set \"pull.rebase\"\nexpects pull --rebase behavior just as much as someone who passes\n--rebase on the command line. The issue in question is what someone who\nhas not made any changes to the settings expects to happen with a plain\n\"git pull\", and I certainly agree that people who are not power users\nexpect a fast-forward (I try not to force my opinions on workflow or\nstyle when onboarding people to Git, but I do always recommend\n\"pull.ff=only\" because I know this is a perennial pitfall).\n\nThe problem is that, as it stands now, this would just leave the user\nwith a cryptic error message (\"Not possible to fast-forward, aborting\")\nwhen they wanted to see remote changes. I think this might warrant an\neven more expanded message than the short one in this patch, but I'm\nnot sure exactly what it should say - there are a few things the user\nmight expect, but an error message isn't the best place for a crash\ncourse.\n"},{"id":"410616","messageId":"X7xlz8NAnsh4SE9l@coredump.intra.peff.net","threadId":"54697","inReplyTo":"CAMP44s3Y3BEbPM_69uxmQWiBq2CqwBo4w13M43WvU4nUQZha8g@mail.gmail.com","subject":"Re: [PATCH v7 1/1] pull: add ff-only option","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-11-24T01:45:51Z","receivedAt":"2020-11-24T01:45:55Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Nov 23, 2020 at 05:51:42PM -0600, Felipe Contreras wrote:\n\n> > On the other hand, it looks quite funny for that single variable\n> > that controls the way how pull works, whether rebase or merge is\n> > used, is pull.REBASE.\n> \n> Which is precisely why I wanted to rename it to pull.mode.\n> \n> In my option git pull should have three main modes:\n> \n> 1. fast-forward only\n> 2. merge\n> 3. rebase\n> \n> The fast-forward only mode can be considered a merge, or a rebase,\n> doesn't matter.\n\nI agree that is much nicer. I'd worry a bit though that it may be\nconfusing to users to have this new mode option _and_ the existing\npull.rebase and pull.ff options, which overlap (but not completely). It\nmight be something we could solve with good documentation, though.\n\n-Peff\n"},{"id":"410617","messageId":"CAMMLpeQmJ7TjMKvtjdczyRX+Kebc9DDDyOJthpA6AwxQqy022Q@mail.gmail.com","threadId":"54697","inReplyTo":"C7B2K1BLPDIO.1D6XVJIWIG3UZ@ziyou.local","subject":"Re: [PATCH v7 1/1] pull: add ff-only option","fromName":"Alex Henrie","fromEmail":"alexhenrie24@gmail.com","sentAt":"2020-11-24T01:51:16Z","receivedAt":"2020-11-24T01:51:52Z","isPatch":true,"sender":{"key":"alexhenrie24@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5951993?v=4"},"body":"On Mon, Nov 23, 2020 at 5:52 PM Raymond E. Pasco wrote:\n>\n> I feel like the parsimonious change to make is simply defaulting the\n> existing \"pull.ff\" to \"only\". I think someone who has set \"pull.rebase\"\n> expects pull --rebase behavior just as much as someone who passes\n> --rebase on the command line. The issue in question is what someone who\n> has not made any changes to the settings expects to happen with a plain\n> \"git pull\", and I certainly agree that people who are not power users\n> expect a fast-forward (I try not to force my opinions on workflow or\n> style when onboarding people to Git, but I do always recommend\n> \"pull.ff=only\" because I know this is a perennial pitfall).\n>\n> The problem is that, as it stands now, this would just leave the user\n> with a cryptic error message (\"Not possible to fast-forward, aborting\")\n> when they wanted to see remote changes. I think this might warrant an\n> even more expanded message than the short one in this patch, but I'm\n> not sure exactly what it should say - there are a few things the user\n> might expect, but an error message isn't the best place for a crash\n> course.\n\nAnother problem is that when pull.ff=only but you really do want to\nallow merging if fast-forwarding is impossible, having to type `git\npull --ff` to get that behavior is *very* counterintuitive :-(\n\n-Alex\n"},{"id":"410630","messageId":"CAMP44s1QjgOAq6trBmw5Bxt8aXRqVkOStztFOpJr+ooMEG7K0A@mail.gmail.com","threadId":"54697","inReplyTo":"CAMMLpeQmJ7TjMKvtjdczyRX+Kebc9DDDyOJthpA6AwxQqy022Q@mail.gmail.com","subject":"Re: [PATCH v7 1/1] pull: add ff-only option","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-11-24T03:45:13Z","receivedAt":"2020-11-24T03:45:29Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Mon, Nov 23, 2020 at 7:51 PM Alex Henrie wrote:\n>\n> On Mon, Nov 23, 2020 at 5:52 PM Raymond E. Pasco wrote:\n> >\n> > I feel like the parsimonious change to make is simply defaulting the\n> > existing \"pull.ff\" to \"only\". I think someone who has set \"pull.rebase\"\n> > expects pull --rebase behavior just as much as someone who passes\n> > --rebase on the command line. The issue in question is what someone who\n> > has not made any changes to the settings expects to happen with a plain\n> > \"git pull\", and I certainly agree that people who are not power users\n> > expect a fast-forward (I try not to force my opinions on workflow or\n> > style when onboarding people to Git, but I do always recommend\n> > \"pull.ff=only\" because I know this is a perennial pitfall).\n> >\n> > The problem is that, as it stands now, this would just leave the user\n> > with a cryptic error message (\"Not possible to fast-forward, aborting\")\n> > when they wanted to see remote changes. I think this might warrant an\n> > even more expanded message than the short one in this patch, but I'm\n> > not sure exactly what it should say - there are a few things the user\n> > might expect, but an error message isn't the best place for a crash\n> > course.\n>\n> Another problem is that when pull.ff=only but you really do want to\n> allow merging if fast-forwarding is impossible, having to type `git\n> pull --ff` to get that behavior is *very* counterintuitive :-(\n\nIndeed.\n\nIt would be much more intuitive to type \"git pull --merge\" which would\noverride some default (e.g. do not merge unless it's a fast-forward).\n\n-- \nFelipe Contreras\n"}]}