{"thread":{"id":"34821","subject":"[PATCH 0/3] Reject non-ff pulls by default","startedAt":"2013-08-31T22:38:07Z","lastAt":"2013-09-13T00:55:00Z","messageCount":84,"participants":["Felipe Contreras","Junio C Hamano","John Keeping","Jeff King","Philip Oakley","John Szakmeister","Greg Troxel","Richard Hansen","Jonathan Nieder","brian m. carlson","Ramkumar Ramachandra","Matthieu Moy"],"isPatch":true,"patchVersion":1,"patchTotal":3},"messages":[{"id":"226453","messageId":"1377988690-23460-1-git-send-email-felipe.contreras@gmail.com","threadId":"34821","inReplyTo":null,"subject":"[PATCH 0/3] Reject non-ff pulls by default","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-08-31T22:38:07Z","receivedAt":"2013-08-31T22:38:07Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio already sent a similar patch, but I think this is simpler.\n\nFelipe Contreras (3):\n merge: simplify ff-only option\n t: replace pulls with merges\n pull: reject non-ff pulls by default\n\n Documentation/git-pull.txt | 1 +\n builtin/merge.c | 20 ++++++++++----------\n git-pull.sh | 9 ++++++++-\n t/annotate-tests.sh | 2 +-\n t/t4200-rerere.sh | 2 +-\n t/t5500-fetch-pack.sh | 2 +-\n t/t5520-pull.sh | 33 +++++++++++++++++++++++++++++++++\n t/t5524-pull-msg.sh | 2 +-\n t/t5700-clone-reference.sh | 4 ++--\n t/t6022-merge-rename.sh | 20 ++++++++++----------\n t/t6026-merge-attr.sh | 2 +-\n t/t6029-merge-subtree.sh | 4 ++--\n t/t6037-merge-ours-theirs.sh | 10 +++++-----\n t/t7603-merge-reduce-heads.sh | 2 +-\n t/t9114-git-svn-dcommit-merge.sh | 2 +-\n t/t9500-gitweb-standalone-no-errors.sh | 2 +-\n 16 files changed, 79 insertions(+), 38 deletions(-)\n\n-- \n1.8.4-337-g7358a66-dirty\n"},{"id":"226454","messageId":"1377988690-23460-2-git-send-email-felipe.contreras@gmail.com","threadId":"34821","inReplyTo":"1377988690-23460-1-git-send-email-felipe.contreras@gmail.com","subject":"[PATCH 1/3] merge: simplify ff-only option","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-08-31T22:38:08Z","receivedAt":"2013-08-31T22:38:08Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"No functional changes.\n\nSigned-off-by: Felipe Contreras \n---\n builtin/merge.c | 11 ++---------\n 1 file changed, 2 insertions(+), 9 deletions(-)\n\ndiff --git a/builtin/merge.c b/builtin/merge.c\nindex 34a6166..da9fc08 100644\n--- a/builtin/merge.c\n+++ b/builtin/merge.c\n@@ -186,13 +186,6 @@ static int option_parse_n(const struct option *opt,\n \treturn 0;\n }\n \n-static int option_parse_ff_only(const struct option *opt,\n-\t\t\t const char *arg, int unset)\n-{\n-\tfast_forward = FF_ONLY;\n-\treturn 0;\n-}\n-\n static struct option builtin_merge_options[] = {\n \t{ OPTION_CALLBACK, 'n', NULL, NULL, NULL,\n \t\tN_(\"do not show a diffstat at the end of the merge\"),\n@@ -210,9 +203,9 @@ static struct option builtin_merge_options[] = {\n \tOPT_BOOL('e', \"edit\", &option_edit,\n \t\tN_(\"edit message before committing\")),\n \tOPT_SET_INT(0, \"ff\", &fast_forward, N_(\"allow fast-forward (default)\"), FF_ALLOW),\n-\t{ OPTION_CALLBACK, 0, \"ff-only\", NULL, NULL,\n+\t{ OPTION_SET_INT, 0, \"ff-only\", &fast_forward, NULL,\n \t\tN_(\"abort if fast-forward is not possible\"),\n-\t\tPARSE_OPT_NOARG | PARSE_OPT_NONEG, option_parse_ff_only },\n+\t\tPARSE_OPT_NOARG | PARSE_OPT_NONEG, NULL, FF_ONLY },\n \tOPT_RERERE_AUTOUPDATE(&allow_rerere_auto),\n \tOPT_BOOL(0, \"verify-signatures\", &verify_signatures,\n \t\tN_(\"Verify that the named commit has a valid GPG signature\")),\n-- \n1.8.4-337-g7358a66-dirty\n"},{"id":"226455","messageId":"1377988690-23460-3-git-send-email-felipe.contreras@gmail.com","threadId":"34821","inReplyTo":"1377988690-23460-1-git-send-email-felipe.contreras@gmail.com","subject":"[PATCH 2/3] t: replace pulls with merges","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-08-31T22:38:09Z","receivedAt":"2013-08-31T22:38:09Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"This is what the code intended.\n\nNo functional changes.\n\nSigned-off-by: Felipe Contreras \n---\n t/annotate-tests.sh | 2 +-\n t/t4200-rerere.sh | 2 +-\n t/t9114-git-svn-dcommit-merge.sh | 2 +-\n t/t9500-gitweb-standalone-no-errors.sh | 2 +-\n 4 files changed, 4 insertions(+), 4 deletions(-)\n\ndiff --git a/t/annotate-tests.sh b/t/annotate-tests.sh\nindex d4e7f47..01deece 100644\n--- a/t/annotate-tests.sh\n+++ b/t/annotate-tests.sh\n@@ -92,7 +92,7 @@ test_expect_success 'blame 2 authors + 1 branch2 author' '\n '\n \n test_expect_success 'merge branch1 & branch2' '\n-\tgit pull . branch1\n+\tgit merge branch1\n '\n \n test_expect_success 'blame 2 authors + 2 merged-in authors' '\ndiff --git a/t/t4200-rerere.sh b/t/t4200-rerere.sh\nindex 7f6666f..cf19eb7 100755\n--- a/t/t4200-rerere.sh\n+++ b/t/t4200-rerere.sh\n@@ -172,7 +172,7 @@ test_expect_success 'first postimage wins' '\n \tgit show second^:a1 | sed \"s/To die: t/To die! T/\" >a1 &&\n \tgit commit -q -a -m third &&\n \n-\ttest_must_fail git pull . first &&\n+\ttest_must_fail git merge first &&\n \t# rerere kicked in\n \t! grep \"^=======\\$\" a1 &&\n \ttest_cmp expect a1\ndiff --git a/t/t9114-git-svn-dcommit-merge.sh b/t/t9114-git-svn-dcommit-merge.sh\nindex f524d2f..d33d714 100755\n--- a/t/t9114-git-svn-dcommit-merge.sh\n+++ b/t/t9114-git-svn-dcommit-merge.sh\n@@ -62,7 +62,7 @@ test_expect_success 'setup git mirror and merge' '\n \techo friend > README &&\n \tcat tmp >> README &&\n \tgit commit -a -m \"friend\" &&\n-\tgit pull . merge\n+\tgit merge merge\n \t'\n \n test_debug 'gitk --all & sleep 1'\ndiff --git a/t/t9500-gitweb-standalone-no-errors.sh b/t/t9500-gitweb-standalone-no-errors.sh\nindex 6fca193..3864388 100755\n--- a/t/t9500-gitweb-standalone-no-errors.sh\n+++ b/t/t9500-gitweb-standalone-no-errors.sh\n@@ -328,7 +328,7 @@ test_expect_success \\\n \t git add b &&\n \t git commit -a -m \"On branch\" &&\n \t git checkout master &&\n-\t git pull . b &&\n+\t git merge b &&\n \t git tag merge_commit'\n \n test_expect_success \\\n-- \n1.8.4-337-g7358a66-dirty\n"},{"id":"226456","messageId":"1377988690-23460-4-git-send-email-felipe.contreras@gmail.com","threadId":"34821","inReplyTo":"1377988690-23460-1-git-send-email-felipe.contreras@gmail.com","subject":"[PATCH 3/3] pull: reject non-ff pulls by default","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-08-31T22:38:10Z","receivedAt":"2013-08-31T22:38:10Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"For the full discussion:\n\nhttp://thread.gmane.org/gmane.comp.version-control.git/225146/focus=225305\n\nThe user still can specify 'git pull --merge' to restore the old\nbehavior, or 'git config pull.rebase false'.\n\nSigned-off-by: Felipe Contreras \n---\n Documentation/git-pull.txt | 1 +\n builtin/merge.c | 9 ++++++++-\n git-pull.sh | 9 ++++++++-\n t/t5500-fetch-pack.sh | 2 +-\n t/t5520-pull.sh | 33 +++++++++++++++++++++++++++++++++\n t/t5524-pull-msg.sh | 2 +-\n t/t5700-clone-reference.sh | 4 ++--\n t/t6022-merge-rename.sh | 20 ++++++++++----------\n t/t6026-merge-attr.sh | 2 +-\n t/t6029-merge-subtree.sh | 4 ++--\n t/t6037-merge-ours-theirs.sh | 10 +++++-----\n t/t7603-merge-reduce-heads.sh | 2 +-\n 12 files changed, 73 insertions(+), 25 deletions(-)\n\ndiff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt\nindex 6ef8d59..1833779 100644\n--- a/Documentation/git-pull.txt\n+++ b/Documentation/git-pull.txt\n@@ -119,6 +119,7 @@ It rewrites history, which does not bode well when you\n published that history already. Do *not* use this option\n unless you have read linkgit:git-rebase[1] carefully.\n \n+--merge::\n --no-rebase::\n \tOverride earlier --rebase.\n \ndiff --git a/builtin/merge.c b/builtin/merge.c\nindex da9fc08..97b4205 100644\n--- a/builtin/merge.c\n+++ b/builtin/merge.c\n@@ -1437,8 +1437,15 @@ int cmd_merge(int argc, const char **argv, const char *prefix)\n \t\t}\n \t}\n \n-\tif (fast_forward == FF_ONLY)\n+\tif (fast_forward == FF_ONLY) {\n+\t\tconst char *msg = getenv(\"GIT_MERGE_FF_ONLY_HELP\");\n+\t\tif (msg) {\n+\t\t\tfprintf(stderr, \"%s\\n\", msg);\n+\t\t\tret = 1;\n+\t\t\tgoto done;\n+\t\t}\n \t\tdie(_(\"Not possible to fast-forward, aborting.\"));\n+\t}\n \n \t/* We are going to make a new commit. */\n \tgit_committer_info(IDENT_STRICT);\ndiff --git a/git-pull.sh b/git-pull.sh\nindex f0df41c..c6b576b 100755\n--- a/git-pull.sh\n+++ b/git-pull.sh\n@@ -113,7 +113,8 @@ do\n \t-r|--r|--re|--reb|--reba|--rebas|--rebase)\n \t\trebase=true\n \t\t;;\n-\t--no-r|--no-re|--no-reb|--no-reba|--no-rebas|--no-rebase)\n+\t--no-r|--no-re|--no-reb|--no-reba|--no-rebas|--no-rebase|\\\n+\t-m|--m|--me|--mer|--merg|--merge)\n \t\trebase=false\n \t\t;;\n \t--recurse-submodules)\n@@ -289,6 +290,12 @@ then\n \tfi\n fi\n \n+if test -z \"$rebase$no_ff$ff_only${squash#--no-squash}\"\n+then\n+\tff_only=--ff-only\n+\texport GIT_MERGE_FF_ONLY_HELP=\"The pull was not fast-forward, please either merge or rebase.\"\n+fi\n+\n merge_name=$(git fmt-merge-msg $log_arg <\"$GIT_DIR/FETCH_HEAD\") || exit\n case \"$rebase\" in\n true)\ndiff --git a/t/t5500-fetch-pack.sh b/t/t5500-fetch-pack.sh\nindex fd2598e..f1a068f 100755\n--- a/t/t5500-fetch-pack.sh\n+++ b/t/t5500-fetch-pack.sh\n@@ -259,7 +259,7 @@ test_expect_success 'clone shallow object count' '\n test_expect_success 'pull in shallow repo with missing merge base' '\n \t(\n \t\tcd shallow &&\n-\t\ttest_must_fail git pull --depth 4 .. A\n+\t\ttest_must_fail git pull --merge --depth 4 .. A\n \t)\n '\n \ndiff --git a/t/t5520-pull.sh b/t/t5520-pull.sh\nindex ed4d9c8..c0c50a2 100755\n--- a/t/t5520-pull.sh\n+++ b/t/t5520-pull.sh\n@@ -284,4 +284,37 @@ test_expect_success 'git pull --rebase against local branch' '\n \ttest file = \"$(cat file2)\"\n '\n \n+test_expect_success 'git pull fast-forward' '\n+\ttest_when_finished \"git checkout master && git branch -D other test\" &&\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' '\n+\ttest_when_finished \"git checkout master && git branch -D other test\" &&\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 (merge)' '\n+\ttest_when_finished \"git checkout master && git branch -D other test\" &&\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 --merge\n+'\n+\n test_done\ndiff --git a/t/t5524-pull-msg.sh b/t/t5524-pull-msg.sh\nindex 8cccecc..ec9f413 100755\n--- a/t/t5524-pull-msg.sh\n+++ b/t/t5524-pull-msg.sh\n@@ -25,7 +25,7 @@ test_expect_success setup '\n test_expect_success pull '\n (\n \tcd cloned &&\n-\tgit pull --log &&\n+\tgit pull --merge --log &&\n \tgit log -2 &&\n \tgit cat-file commit HEAD >result &&\n \tgrep Dollar result\ndiff --git a/t/t5700-clone-reference.sh b/t/t5700-clone-reference.sh\nindex 6537911..306badf 100755\n--- a/t/t5700-clone-reference.sh\n+++ b/t/t5700-clone-reference.sh\n@@ -94,7 +94,7 @@ cd \"$base_dir\"\n \n test_expect_success 'pulling changes from origin' \\\n 'cd C &&\n-git pull origin'\n+git pull --merge origin'\n \n cd \"$base_dir\"\n \n@@ -109,7 +109,7 @@ cd \"$base_dir\"\n \n test_expect_success 'pulling changes from origin' \\\n 'cd D &&\n-git pull origin'\n+git pull --merge origin'\n \n cd \"$base_dir\"\n \ndiff --git a/t/t6022-merge-rename.sh b/t/t6022-merge-rename.sh\nindex c680f78..6c7fdc1 100755\n--- a/t/t6022-merge-rename.sh\n+++ b/t/t6022-merge-rename.sh\n@@ -100,7 +100,7 @@ git checkout master'\n test_expect_success 'pull renaming branch into unrenaming one' \\\n '\n \tgit show-branch &&\n-\ttest_expect_code 1 git pull . white &&\n+\ttest_expect_code 1 git pull --merge . white &&\n \tgit ls-files -s &&\n \tgit ls-files -u B >b.stages &&\n \ttest_line_count = 3 b.stages &&\n@@ -118,7 +118,7 @@ test_expect_success 'pull renaming branch into another renaming one' \\\n \trm -f B &&\n \tgit reset --hard &&\n \tgit checkout red &&\n-\ttest_expect_code 1 git pull . white &&\n+\ttest_expect_code 1 git pull --merge . white &&\n \tgit ls-files -u B >b.stages &&\n \ttest_line_count = 3 b.stages &&\n \tgit ls-files -s N >n.stages &&\n@@ -134,7 +134,7 @@ test_expect_success 'pull unrenaming branch into renaming one' \\\n '\n \tgit reset --hard &&\n \tgit show-branch &&\n-\ttest_expect_code 1 git pull . master &&\n+\ttest_expect_code 1 git pull --merge . master &&\n \tgit ls-files -u B >b.stages &&\n \ttest_line_count = 3 b.stages &&\n \tgit ls-files -s N >n.stages &&\n@@ -150,7 +150,7 @@ test_expect_success 'pull conflicting renames' \\\n '\n \tgit reset --hard &&\n \tgit show-branch &&\n-\ttest_expect_code 1 git pull . blue &&\n+\ttest_expect_code 1 git pull --merge . blue &&\n \tgit ls-files -u A >a.stages &&\n \ttest_line_count = 1 a.stages &&\n \tgit ls-files -u B >b.stages &&\n@@ -170,7 +170,7 @@ test_expect_success 'interference with untracked working tree file' '\n \tgit reset --hard &&\n \tgit show-branch &&\n \techo >A this file should not matter &&\n-\ttest_expect_code 1 git pull . white &&\n+\ttest_expect_code 1 git pull --merge . white &&\n \ttest_path_is_file A\n '\n \n@@ -180,7 +180,7 @@ test_expect_success 'interference with untracked working tree file' '\n \tgit show-branch &&\n \trm -f A &&\n \techo >A this file should not matter &&\n-\ttest_expect_code 1 git pull . red &&\n+\ttest_expect_code 1 git pull --merge . red &&\n \ttest_path_is_file A\n '\n \n@@ -190,7 +190,7 @@ test_expect_success 'interference with untracked working tree file' '\n \tgit checkout -f master &&\n \tgit tag -f anchor &&\n \tgit show-branch &&\n-\tgit pull . yellow &&\n+\tgit pull --merge . yellow &&\n \ttest_path_is_missing M &&\n \tgit reset --hard anchor\n '\n@@ -203,7 +203,7 @@ test_expect_success 'updated working tree file should prevent the merge' '\n \tgit show-branch &&\n \techo >>M one line addition &&\n \tcat M >M.saved &&\n-\ttest_expect_code 128 git pull . yellow &&\n+\ttest_expect_code 128 git pull --merge . yellow &&\n \ttest_cmp M M.saved &&\n \trm -f M.saved\n '\n@@ -217,7 +217,7 @@ test_expect_success 'updated working tree file should prevent the merge' '\n \techo >>M one line addition &&\n \tcat M >M.saved &&\n \tgit update-index M &&\n-\ttest_expect_code 128 git pull . yellow &&\n+\ttest_expect_code 128 git pull --merge . yellow &&\n \ttest_cmp M M.saved &&\n \trm -f M.saved\n '\n@@ -229,7 +229,7 @@ test_expect_success 'interference with untracked working tree file' '\n \tgit tag -f anchor &&\n \tgit show-branch &&\n \techo >M this file should not matter &&\n-\tgit pull . master &&\n+\tgit pull --merge . master &&\n \ttest_path_is_file M &&\n \t! {\n \t\tgit ls-files -s |\ndiff --git a/t/t6026-merge-attr.sh b/t/t6026-merge-attr.sh\nindex 5e43997..5428f19 100755\n--- a/t/t6026-merge-attr.sh\n+++ b/t/t6026-merge-attr.sh\n@@ -172,7 +172,7 @@ test_expect_success 'up-to-date merge without common ancestor' '\n \ttest_tick &&\n \t(\n \t\tcd repo1 &&\n-\t\tgit pull ../repo2 master\n+\t\tgit pull --merge ../repo2 master\n \t)\n '\n \ndiff --git a/t/t6029-merge-subtree.sh b/t/t6029-merge-subtree.sh\nindex 73fc240..0eeec04 100755\n--- a/t/t6029-merge-subtree.sh\n+++ b/t/t6029-merge-subtree.sh\n@@ -98,7 +98,7 @@ test_expect_success 'initial ambiguous subtree' '\n test_expect_success 'merge using explicit' '\n \tcd ../git &&\n \tgit reset --hard master2 &&\n-\tgit pull -Xsubtree=git-gui gui master2 &&\n+\tgit pull --merge -Xsubtree=git-gui gui master2 &&\n \tgit ls-files -s >actual &&\n \t(\n \t\techo \"100644 $o3 0\tgit-gui/git-gui.sh\"\n@@ -111,7 +111,7 @@ test_expect_success 'merge using explicit' '\n test_expect_success 'merge2 using explicit' '\n \tcd ../git &&\n \tgit reset --hard master2 &&\n-\tgit pull -Xsubtree=git-gui2 gui master2 &&\n+\tgit pull --merge -Xsubtree=git-gui2 gui master2 &&\n \tgit ls-files -s >actual &&\n \t(\n \t\techo \"100644 $o1 0\tgit-gui/git-gui.sh\"\ndiff --git a/t/t6037-merge-ours-theirs.sh b/t/t6037-merge-ours-theirs.sh\nindex 3889eca..927e67c 100755\n--- a/t/t6037-merge-ours-theirs.sh\n+++ b/t/t6037-merge-ours-theirs.sh\n@@ -66,11 +66,11 @@ test_expect_success 'binary file with -Xours/-Xtheirs' '\n '\n \n test_expect_success 'pull passes -X to underlying merge' '\n-\tgit reset --hard master && git pull -s recursive -Xours . side &&\n-\tgit reset --hard master && git pull -s recursive -X ours . side &&\n-\tgit reset --hard master && git pull -s recursive -Xtheirs . side &&\n-\tgit reset --hard master && git pull -s recursive -X theirs . side &&\n-\tgit reset --hard master && test_must_fail git pull -s recursive -X bork . side\n+\tgit reset --hard master && git pull --merge -s recursive -Xours . side &&\n+\tgit reset --hard master && git pull --merge -s recursive -X ours . side &&\n+\tgit reset --hard master && git pull --merge -s recursive -Xtheirs . side &&\n+\tgit reset --hard master && git pull --merge -s recursive -X theirs . side &&\n+\tgit reset --hard master && test_must_fail git pull --merge -s recursive -X bork . side\n '\n \n test_done\ndiff --git a/t/t7603-merge-reduce-heads.sh b/t/t7603-merge-reduce-heads.sh\nindex 9894895..566b1c1 100755\n--- a/t/t7603-merge-reduce-heads.sh\n+++ b/t/t7603-merge-reduce-heads.sh\n@@ -68,7 +68,7 @@ test_expect_success 'merge c1 with c2, c3, c4, c5' '\n \n test_expect_success 'pull c2, c3, c4, c5 into c1' '\n \tgit reset --hard c1 &&\n-\tgit pull . c2 c3 c4 c5 &&\n+\tgit pull --merge . c2 c3 c4 c5 &&\n \ttest \"$(git rev-parse c1)\" != \"$(git rev-parse HEAD)\" &&\n \ttest \"$(git rev-parse c1)\" = \"$(git rev-parse HEAD^1)\" &&\n \ttest \"$(git rev-parse c2)\" = \"$(git rev-parse HEAD^2)\" &&\n-- \n1.8.4-337-g7358a66-dirty\n"},{"id":"226641","messageId":"xmqqd2opu8hr.fsf@gitster.dls.corp.google.com","threadId":"34821","inReplyTo":"1377988690-23460-1-git-send-email-felipe.contreras@gmail.com","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-09-03T17:21:04Z","receivedAt":"2013-09-03T17:21:04Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> Junio already sent a similar patch, but I think this is simpler.\n\nI agree that this is simpler, but I am not sure if the behaviour is\nnecessarily better (note that this is different from saying \"I think\nthe behaviour of this patch is worse\"). The motivation I read from\nthe original discussion was that new people did \"git pull\" (no other\nparameters) to \"sync my tree with the central repository\" as if it\nwere SVN, and because we are not SVN, projects that prefer rebases\nwere unhappy, and the other one was to address *only* that use case.\nI do not personally like that special casing (i.e. \"only when no\n'integrate with what from where' is given\"), and applying the \"you\nmust be explicit between rebase and merge\" like this series does\nuniformly might (or might not) be a good thing. I dunno.\n\nThe difference in changes needed to the test suite is illustrative;\nthis series affects any use of \"git pull\" (with or without explicit\n\"what to integrate with and from where\"), unlike the other one that\nonly affects the case where \"git pull\" was not given \"what to\nintegrate with and from where\". I think an earlier draft I did for\nthe previous one did not special case \"only when no 'integrate with\nwhat from where' is given\" and had to touch all the places in the\ntest in a similar way.\n"},{"id":"226679","messageId":"CAMP44s2NzzS48BBpD_oQ24t2SYETte7_U4+O+32SOo5qhooQew@mail.gmail.com","threadId":"34821","inReplyTo":"xmqqd2opu8hr.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-09-03T21:50:46Z","receivedAt":"2013-09-03T21:50:46Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, Sep 3, 2013 at 12:21 PM, Junio C Hamano wrote:\n> Felipe Contreras writes:\n>\n>> Junio already sent a similar patch, but I think this is simpler.\n>\n> I agree that this is simpler, but I am not sure if the behaviour is\n> necessarily better (note that this is different from saying \"I think\n> the behaviour of this patch is worse\"). The motivation I read from\n> the original discussion was that new people did \"git pull\" (no other\n> parameters) to \"sync my tree with the central repository\" as if it\n> were SVN, and because we are not SVN, projects that prefer rebases\n> were unhappy, and the other one was to address *only* that use case.\n> I do not personally like that special casing (i.e. \"only when no\n> 'integrate with what from where' is given\"), and applying the \"you\n> must be explicit between rebase and merge\" like this series does\n> uniformly might (or might not) be a good thing. I dunno.\n\nAs I already said; there's is essentially no difference between \"git\npull\" and \"git pull origin\".\n\n> The difference in changes needed to the test suite is illustrative;\n> this series affects any use of \"git pull\" (with or without explicit\n> \"what to integrate with and from where\"), unlike the other one that\n> only affects the case where \"git pull\" was not given \"what to\n> integrate with and from where\". I think an earlier draft I did for\n> the previous one did not special case \"only when no 'integrate with\n> what from where' is given\" and had to touch all the places in the\n> test in a similar way.\n\nYeah, that version affects less, but it also doesn't achieve what we\nactually want.\n\nEither way, that's why I sent another version that doesn't need\nmodifications on the tests.\n\n-- \nFelipe Contreras\n"},{"id":"226686","messageId":"xmqqfvtlpm2l.fsf@gitster.dls.corp.google.com","threadId":"34821","inReplyTo":"CAMP44s2NzzS48BBpD_oQ24t2SYETte7_U4+O+32SOo5qhooQew@mail.gmail.com","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-09-03T22:38:58Z","receivedAt":"2013-09-03T22:38:58Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> On Tue, Sep 3, 2013 at 12:21 PM, Junio C Hamano wrote:\n>> Felipe Contreras writes:\n>>\n>>> Junio already sent a similar patch, but I think this is simpler.\n>>\n>> I agree that this is simpler, but I am not sure if the behaviour is\n>> necessarily better (note that this is different from saying \"I think\n>> the behaviour of this patch is worse\"). The motivation I read from\n>> the original discussion was that new people did \"git pull\" (no other\n>> parameters) to \"sync my tree with the central repository\" as if it\n>> were SVN, and because we are not SVN, projects that prefer rebases\n>> were unhappy, and the other one was to address *only* that use case.\n>> I do not personally like that special casing (i.e. \"only when no\n>> 'integrate with what from where' is given\"), and applying the \"you\n>> must be explicit between rebase and merge\" like this series does\n>> uniformly might (or might not) be a good thing. I dunno.\n>\n> As I already said; there's is essentially no difference between \"git\n> pull\" and \"git pull origin\".\n\nWe know what you said earlier. That does not make it right or wrong,\nbut I do not think it is in line with the original discussion (that\nis why John Keeping is kept on the Cc: line).\n\n>> The difference in changes needed to the test suite is illustrative;\n>> this series affects any use of \"git pull\" (with or without explicit\n>> \"what to integrate with and from where\"), unlike the other one that\n>> only affects the case where \"git pull\" was not given \"what to\n>> integrate with and from where\". I think an earlier draft I did for\n>> the previous one did not special case \"only when no 'integrate with\n>> what from where' is given\" and had to touch all the places in the\n>> test in a similar way.\n>\n> Yeah, that version affects less, but it also doesn't achieve what we\n> actually want.\n\nI do not think we know what we want is to affect \"git pull origin\".\n"},{"id":"226690","messageId":"CAMP44s3XSVLCn7M33D4uZwUoEsY6wj34N7L8MF8bGOx0+fmV2w@mail.gmail.com","threadId":"34821","inReplyTo":"xmqqfvtlpm2l.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-09-03T22:59:38Z","receivedAt":"2013-09-03T22:59:38Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, Sep 3, 2013 at 5:38 PM, Junio C Hamano wrote:\n> Felipe Contreras writes:\n>\n>> On Tue, Sep 3, 2013 at 12:21 PM, Junio C Hamano wrote:\n>>> Felipe Contreras writes:\n>>>\n>>>> Junio already sent a similar patch, but I think this is simpler.\n>>>\n>>> I agree that this is simpler, but I am not sure if the behaviour is\n>>> necessarily better (note that this is different from saying \"I think\n>>> the behaviour of this patch is worse\"). The motivation I read from\n>>> the original discussion was that new people did \"git pull\" (no other\n>>> parameters) to \"sync my tree with the central repository\" as if it\n>>> were SVN, and because we are not SVN, projects that prefer rebases\n>>> were unhappy, and the other one was to address *only* that use case.\n>>> I do not personally like that special casing (i.e. \"only when no\n>>> 'integrate with what from where' is given\"), and applying the \"you\n>>> must be explicit between rebase and merge\" like this series does\n>>> uniformly might (or might not) be a good thing. I dunno.\n>>\n>> As I already said; there's is essentially no difference between \"git\n>> pull\" and \"git pull origin\".\n>\n> We know what you said earlier. That does not make it right or wrong,\n> but I do not think it is in line with the original discussion (that\n> is why John Keeping is kept on the Cc: line).\n\nAnd nobody provided any argument against that claim. People staying\nsilent doesn't make it wrong.\n\n>>> The difference in changes needed to the test suite is illustrative;\n>>> this series affects any use of \"git pull\" (with or without explicit\n>>> \"what to integrate with and from where\"), unlike the other one that\n>>> only affects the case where \"git pull\" was not given \"what to\n>>> integrate with and from where\". I think an earlier draft I did for\n>>> the previous one did not special case \"only when no 'integrate with\n>>> what from where' is given\" and had to touch all the places in the\n>>> test in a similar way.\n>>\n>> Yeah, that version affects less, but it also doesn't achieve what we\n>> actually want.\n>\n> I do not think we know what we want is to affect \"git pull origin\".\n\nOf course we do.\n\nWhat we want is to make \"git pull\" more user-friendly, specially to\nnewcomers, and specially those that come from centralized VCS, where\n\"tool pull\" updates the checkout, and thus we want \"git pull\" not to\ncreate merges inadvertently, and the best way to do that is to warn\nthe user that the merge is non-fast-forward, and he should do a merge\nor rebase.\n\nThe fact that a particular user might have learned about remotes and\ndid \"git pull origin\" instead is irrelevant, he would still want to be\nwarned about non-fast-forward merges.\n\nEverybody would want to be warned about that by default, I know I\nwould, I might even start using 'git pull' again, and so countless\npeople that have stopped using 'git pull' precisely for this reason.\n\n-- \nFelipe Contreras\n"},{"id":"226712","messageId":"20130904081047.GB2582@serenity.lan","threadId":"34821","inReplyTo":"xmqqfvtlpm2l.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2013-09-04T08:10:47Z","receivedAt":"2013-09-04T08:10:47Z","isPatch":true,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Tue, Sep 03, 2013 at 03:38:58PM -0700, Junio C Hamano wrote:\n> Felipe Contreras writes:\n> \n> > On Tue, Sep 3, 2013 at 12:21 PM, Junio C Hamano wrote:\n> >> Felipe Contreras writes:\n> >>\n> >>> Junio already sent a similar patch, but I think this is simpler.\n> >>\n> >> I agree that this is simpler, but I am not sure if the behaviour is\n> >> necessarily better (note that this is different from saying \"I think\n> >> the behaviour of this patch is worse\"). The motivation I read from\n> >> the original discussion was that new people did \"git pull\" (no other\n> >> parameters) to \"sync my tree with the central repository\" as if it\n> >> were SVN, and because we are not SVN, projects that prefer rebases\n> >> were unhappy, and the other one was to address *only* that use case.\n> >> I do not personally like that special casing (i.e. \"only when no\n> >> 'integrate with what from where' is given\"), and applying the \"you\n> >> must be explicit between rebase and merge\" like this series does\n> >> uniformly might (or might not) be a good thing. I dunno.\n> >\n> > As I already said; there's is essentially no difference between \"git\n> > pull\" and \"git pull origin\".\n> \n> We know what you said earlier. That does not make it right or wrong,\n> but I do not think it is in line with the original discussion (that\n> is why John Keeping is kept on the Cc: line).\n\nI think there are two distinct uses for pull, which boil down to:\n\n (1) git pull\n (2) git pull $remote $branch\n\nFor (1) a merge is almost always the wrong thing to do since it will be\nbackwards and break --first-parent.\n\nBut for (2) a merge is almost always the correct thing to do (in fact it\nmay even be correct to create a merge commit even when this fast\nforwards) because this most likely comes for a pull request workflow.\n\n> I do not think we know what we want is to affect \"git pull origin\".\n\nI consider \"git pull $remote\" to be an artifact of the way git-pull is\nimplemented on top of git-fetch; perhaps I'm missing something but I\ncan't see a scenario where this is useful. In the series currently in\n\"next\", we treat this as (2) above but that's primarily because it is\ndifficult to differentiate these in git-pull.sh without adding code to\nunderstand all of the options to git-fetch (or at least those that can\naccept unstuck arguments).\n\nChanging this so that \"git pull $remote\" is treated as (1) would be\nbetter, but I think it is more important to avoid catching case (1) in\nthe same net which is why jc/pull-training-wheel simply checks if \"$#\"\nis zero; the cost of getting this completely right outweighed the\nbenefit of getting code in that will catch 99% of users.\n"},{"id":"226720","messageId":"20130904092527.GB22348@sigill.intra.peff.net","threadId":"34821","inReplyTo":"20130904081047.GB2582@serenity.lan","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-09-04T09:25:27Z","receivedAt":"2013-09-04T09:25:27Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Sep 04, 2013 at 09:10:47AM +0100, John Keeping wrote:\n\n> I think there are two distinct uses for pull, which boil down to:\n> \n> (1) git pull\n> (2) git pull $remote $branch\n> \n> For (1) a merge is almost always the wrong thing to do since it will be\n> backwards and break --first-parent.\n\nIs it always wrong? You are assuming a topic-branch workflow where\n--first-parent is actually meaningful. What about a centralized workflow\nwhere everyone works on \"master\"? The correct thing to do on a non-ff\npush in that case is \"git pull && git push\". Some people would argue\nthat the pull should rebase there, but I think there are valid arguments\neither way. We can discuss in that direction if you want.\n\nI can perhaps buy the argument that it is better to help people who are\nusing a topic branch workflow (which we generally want to encourage) to\navoid making backwards merges, and the cost is that people with sloppy\nworkflows will have to do more work / configuration. But we should be\nclear that this is a tradeoff we are making.\n\nThe patch in jc/pull-training-wheel talks about annoying old timers, but\nI think you may also be annoying clueless new users who simply want an\nsvn-like workflow without thinking too hard about it.\n\n> > I do not think we know what we want is to affect \"git pull origin\".\n> \n> I consider \"git pull $remote\" to be an artifact of the way git-pull is\n> implemented on top of git-fetch; perhaps I'm missing something but I\n> can't see a scenario where this is useful.\n\nImagine a workflow where each topic is in its own repository instead of\nin its own branch inside a repository. Or where each developer has his\nor her own repository, but everybody just works on the master branch of\ntheir repository (or perhaps uses branches, but keeps master as a stable\nbase). Alice is the integration manager; Bob tells her that he has work\nready to integrate. She runs \"git pull ~bob/project\", which will merge\nBob's HEAD.\n\nThis is not very different from the kernel workflow, where Linus may do\na \"git pull $remote\" to fetch a sub-system maintainer's work, except\nthat these days people typically mark the to-be-integrated work in a\n\"for-linus\" branch or tag. However, you can find many \"Merge git://\"\nentries even in recent kernel history.\n\nI think this kind of pull would fall into the same situation as your (2)\nabove.\n\n-Peff\n"},{"id":"226721","messageId":"20130904101643.GC2582@serenity.lan","threadId":"34821","inReplyTo":"20130904092527.GB22348@sigill.intra.peff.net","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2013-09-04T10:16:43Z","receivedAt":"2013-09-04T10:16:43Z","isPatch":true,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Wed, Sep 04, 2013 at 05:25:27AM -0400, Jeff King wrote:\n> On Wed, Sep 04, 2013 at 09:10:47AM +0100, John Keeping wrote:\n> \n> > I think there are two distinct uses for pull, which boil down to:\n> > \n> > (1) git pull\n> > (2) git pull $remote $branch\n> > \n> > For (1) a merge is almost always the wrong thing to do since it will be\n> > backwards and break --first-parent.\n> \n> Is it always wrong? You are assuming a topic-branch workflow where\n> --first-parent is actually meaningful. What about a centralized workflow\n> where everyone works on \"master\"? The correct thing to do on a non-ff\n> push in that case is \"git pull && git push\". Some people would argue\n> that the pull should rebase there, but I think there are valid arguments\n> either way. We can discuss in that direction if you want.\n\nI'm one of the people who argues that it should rebase there ;-) The\npoint of jc/pull-training-wheel is to help users think about that.\n\n> I can perhaps buy the argument that it is better to help people who are\n> using a topic branch workflow (which we generally want to encourage) to\n> avoid making backwards merges, and the cost is that people with sloppy\n> workflows will have to do more work / configuration. But we should be\n> clear that this is a tradeoff we are making.\n> \n> The patch in jc/pull-training-wheel talks about annoying old timers, but\n> I think you may also be annoying clueless new users who simply want an\n> svn-like workflow without thinking too hard about it.\n\nThe scenario I have is a central repository where some developers use a\ntopic branch workflow but others are less familiar with Git and don't\nreally think about what they're doing.\n\n> > > I do not think we know what we want is to affect \"git pull origin\".\n> > \n> > I consider \"git pull $remote\" to be an artifact of the way git-pull is\n> > implemented on top of git-fetch; perhaps I'm missing something but I\n> > can't see a scenario where this is useful.\n> \n> Imagine a workflow where each topic is in its own repository instead of\n> in its own branch inside a repository. Or where each developer has his\n> or her own repository, but everybody just works on the master branch of\n> their repository (or perhaps uses branches, but keeps master as a stable\n> base). Alice is the integration manager; Bob tells her that he has work\n> ready to integrate. She runs \"git pull ~bob/project\", which will merge\n> Bob's HEAD.\n> \n> This is not very different from the kernel workflow, where Linus may do\n> a \"git pull $remote\" to fetch a sub-system maintainer's work, except\n> that these days people typically mark the to-be-integrated work in a\n> \"for-linus\" branch or tag. However, you can find many \"Merge git://\"\n> entries even in recent kernel history.\n> \n> I think this kind of pull would fall into the same situation as your (2)\n> above.\n\nOK - so I was missing this. Given this, the jc/pull-training-wheel\nseries is doing the right thing here.\n"},{"id":"226740","messageId":"xmqqhae0o74k.fsf@gitster.dls.corp.google.com","threadId":"34821","inReplyTo":"20130904081047.GB2582@serenity.lan","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-09-04T16:59:23Z","receivedAt":"2013-09-04T16:59:23Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"John Keeping writes:\n\n> On Tue, Sep 03, 2013 at 03:38:58PM -0700, Junio C Hamano wrote:\n>> Felipe Contreras writes:\n>> \n>> > On Tue, Sep 3, 2013 at 12:21 PM, Junio C Hamano wrote:\n>> >> Felipe Contreras writes:\n>> >>\n>> >>> Junio already sent a similar patch, but I think this is simpler.\n>> >>\n>> >> I agree that this is simpler, but I am not sure if the behaviour is\n>> >> necessarily better (note that this is different from saying \"I think\n>> >> the behaviour of this patch is worse\"). The motivation I read from\n>> >> the original discussion was that new people did \"git pull\" (no other\n>> >> parameters) to \"sync my tree with the central repository\" as if it\n>> >> were SVN, and because we are not SVN, projects that prefer rebases\n>> >> were unhappy, and the other one was to address *only* that use case.\n>> >> I do not personally like that special casing (i.e. \"only when no\n>> >> 'integrate with what from where' is given\"), and applying the \"you\n>> >> must be explicit between rebase and merge\" like this series does\n>> >> uniformly might (or might not) be a good thing. I dunno.\n>> >\n>> > As I already said; there's is essentially no difference between \"git\n>> > pull\" and \"git pull origin\".\n>> \n>> We know what you said earlier. That does not make it right or wrong,\n>> but I do not think it is in line with the original discussion (that\n>> is why John Keeping is kept on the Cc: line).\n>\n> I think there are two distinct uses for pull, which boil down to:\n>\n> (1) git pull\n> (2) git pull $remote $branch\n>\n> For (1) a merge is almost always the wrong thing to do since it will be\n> backwards and break --first-parent.\n>\n> But for (2) a merge is almost always the correct thing to do (in fact it\n> may even be correct to create a merge commit even when this fast\n> forwards) because this most likely comes for a pull request workflow.\n>\n>> I do not think we know what we want is to affect \"git pull origin\".\n\nI didn't mean to limit this to \"with an explicit 'from where'\nwithout 'which branch'\", but it appears you took it that way.\nI should have added:\n\n I do not think we know what we want is to affect \"git pull\n origin master\", either.\n\nto clarify. But it seems that Peff's later message in this thread\nalready clarifies this point for me ;-)\n\n\n> I consider \"git pull $remote\" to be an artifact of the way git-pull is\n> implemented on top of git-fetch; perhaps I'm missing something but I\n> can't see a scenario where this is useful. In the series currently in\n> \"next\", we treat this as (2) above but that's primarily because it is\n> difficult to differentiate these in git-pull.sh without adding code to\n> understand all of the options to git-fetch (or at least those that can\n> accept unstuck arguments).\n>\n> Changing this so that \"git pull $remote\" is treated as (1) would be\n> better, but I think it is more important to avoid catching case (1) in\n> the same net which is why jc/pull-training-wheel simply checks if \"$#\"\n> is zero; the cost of getting this completely right outweighed the\n> benefit of getting code in that will catch 99% of users.\n"},{"id":"226742","messageId":"xmqqa9jso69u.fsf@gitster.dls.corp.google.com","threadId":"34821","inReplyTo":"20130904081047.GB2582@serenity.lan","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-09-04T17:17:49Z","receivedAt":"2013-09-04T17:17:49Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"John Keeping writes:\n\n> I think there are two distinct uses for pull, which boil down to:\n>\n> (1) git pull\n> (2) git pull $remote $branch\n>\n> For (1) a merge is almost always the wrong thing to do since it will be\n> backwards and break --first-parent.\n>\n> But for (2) a merge is almost always the correct thing to do (in fact it\n> may even be correct to create a merge commit even when this fast\n> forwards) because this most likely comes for a pull request workflow.\n\nPeff already covered (1)---it is highly doubtful that a merge is\n\"almost always wrong\". In fact, if that _were_ the case, we should\nsimply be defaulting to rebase, not failing the command and asking\nbetween merge and rebase like jc/pull-training-wheel topic did.\n\nWe simply do not know what the user wants, as it heavily depends on\nthe project, so we ask the user to choose one (and stick to it).\n\n\nI am not sure about (2), either. Is it really \"almost always the\ncorrect thing to do\"? I tend to think myself that (2) is a lot more\nlikely to prefer merging than (1) would, but I certainly wouldn't\nsay \"almost always\". Again if \"almost always\" were the case,\nwouldn't it make sense for that mode of invocation of the command to\neven defeat \"pull.rebase\" configuration and default to merge, unless\nexplicitly told to \"pull --rebase\" from the command line?\n\n(the last question is rhetoric, if anybody is wondering).\n"},{"id":"226772","messageId":"7DC052455C7C4B50A4EAFC1EF63D006C@PhilipOakley","threadId":"34821","inReplyTo":"xmqqa9jso69u.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-09-04T22:08:46Z","receivedAt":"2013-09-04T22:08:46Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Junio C Hamano\" \n> John Keeping writes:\n>\n>> I think there are two distinct uses for pull, which boil down to:\n>>\n>> (1) git pull\n>> (2) git pull $remote $branch\n>>\n>> For (1) a merge is almost always the wrong thing to do since it will \n>> be\n>> backwards and break --first-parent.\n>>\n>> But for (2) a merge is almost always the correct thing to do (in fact \n>> it\n>> may even be correct to create a merge commit even when this fast\n>> forwards) because this most likely comes for a pull request workflow.\n>\n> Peff already covered (1)---it is highly doubtful that a merge is\n> \"almost always wrong\". In fact, if that _were_ the case, we should\n> simply be defaulting to rebase, not failing the command and asking\n> between merge and rebase like jc/pull-training-wheel topic did.\n>\n> We simply do not know what the user wants, as it heavily depends on\n> the project, so we ask the user to choose one (and stick to it).\n\nWe only offer a limited list. It won't be sufficient for all use cases. \nIt wasn't for me.\n\nThe ability to say 'stop' if it doen't match expectations, as \nthe --no-ff option would give, would be a help, as the user can then \ndecide what to do (read the manual or `google` the problem perhaps ;-). \nthe option of having a hook (if suggested), while suitable for advanced \nusers won't help those that need that help, rather a few simple safe \noptions are needed.\n\nI generally support the ability to set an option to reject non-ff pulls.\n\n>\n> I am not sure about (2), either. Is it really \"almost always the\n> correct thing to do\"? I tend to think myself that (2) is a lot more\n> likely to prefer merging than (1) would, but I certainly wouldn't\n> say \"almost always\". Again if \"almost always\" were the case,\n> wouldn't it make sense for that mode of invocation of the command to\n> even defeat \"pull.rebase\" configuration and default to merge, unless\n> explicitly told to \"pull --rebase\" from the command line?\n>\n> (the last question is rhetoric, if anybody is wondering).\n> --\nPhilip \n"},{"id":"226775","messageId":"xmqqr4d4jird.fsf@gitster.dls.corp.google.com","threadId":"34821","inReplyTo":"7DC052455C7C4B50A4EAFC1EF63D006C@PhilipOakley","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-09-04T22:59:18Z","receivedAt":"2013-09-04T22:59:18Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Philip Oakley\" writes:\n\n> From: \"Junio C Hamano\" \n>> John Keeping writes:\n>>\n>>> I think there are two distinct uses for pull, which boil down to:\n>>>\n>>> (1) git pull\n>> ...\n>> Peff already covered (1)---it is highly doubtful that a merge is\n>> \"almost always wrong\". In fact, if that _were_ the case, we should\n>> simply be defaulting to rebase, not failing the command and asking\n>> between merge and rebase like jc/pull-training-wheel topic did.\n>>\n>> We simply do not know what the user wants, as it heavily depends on\n>> the project, so we ask the user to choose one (and stick to it).\n>\n> We only offer a limited list. It won't be sufficient for all use\n> cases. It wasn't for me.\n\nVery interesting. Tell us more.\n\nWhen \"git pull\" stops because what was fetched in FETCH_HEAD does\nnot fast-forward, then what did _you_ do (and with the knowledge you\ncurrently have, what would you do)? In a single project, would you\nchoose to sometimes rebase and sometimes merge, and if so, what is\nthe choice depend on? \"When I am on these selected branches, I want\nto merge, but on other branches I want to rebase?\"\n\nIf that is the issue you are trying to raise (I cannot tell yet), a\nrepository-wide \"pull.rebase = merge/rebase\" is still too blunt an\ninstrument, but then \"branch..rebase\" can be set to\nselectively override it, so that case is covered.\n\n\t[pull]\n \trebase = merge\n\t[branch \"po/topic\"]\n \trebase = yes\n\nAre there cases where you do not want to either rebase nor merge?\nIf so what do you want to do after \"git pull\" fetches from the other\nside? Nothing?\n\n\tSide note: a knee-jerk response to a \"yes\" answer to the\n\tlast question from me has always been \"then why are you\n\trunning 'git pull' in the first place. The next paragraph is\n\tmy attempt to extend my imagination a bit, stepping outside\n\tthat reaction.\n\nI can imagine users might want to say \"when I am on these small\nnumber of branches, I want to merge (or rebase), but when I am on\nother, majority of my branches, because they are private, unfinished\nand unpublished work, please stop me from accidentally messing their\nhistories with changes from upstream or anywhere else for that\nmatter\". If that is the issue you are trying to raise, because\nthere is no\n\n\t[pull]\n \trebase = fail\n\t[branch \"master\"]\n \trebase = yes\n\nto force \"git pull\" to fail by default on any branch while allowing\nit to rebase (or merge, for that matter) only on a few selected\nbranches, we fall a bit short.\n\nWhich can be solved by adding the above \"fail\" option, and then\nrenaming them to \"pull.integrate\" and \"branch..integrate\" to\nclarify what these variables are about (it is no longer \"do you\nrebase or not---if you choose not to rebase, by definition you are\ngoing to merge\", as there is a third choice to \"fail\"), while\nretaining \"pull.rebase\" and \"branch..rebase\" as a deprecated\nsynonym.\n\nAm I on the right track following (eh, rather \"trying to guess\")\nwhat you are trying to get at?\n"},{"id":"226830","messageId":"20130905080606.GE2582@serenity.lan","threadId":"34821","inReplyTo":"xmqqr4d4jird.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2013-09-05T08:06:06Z","receivedAt":"2013-09-05T08:06:06Z","isPatch":true,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Wed, Sep 04, 2013 at 03:59:18PM -0700, Junio C Hamano wrote:\n> Are there cases where you do not want to either rebase nor merge?\n> If so what do you want to do after \"git pull\" fetches from the other\n> side? Nothing?\n\nOne other thing that I can see being useful occasionally is:\n\n git rebase @{u}@{1} --onto @{u}\n\nwhich allows local commits to be replayed onto a rewritten upstream\nbranch.\n\nAlthough I agree with your side note below that people doing this may be\nbetter off fetching and then updating their local branch, particularly\nif @{1} is not the correct reflog entry for the upstream when they\ncreated the branch.\n\n> \tSide note: a knee-jerk response to a \"yes\" answer to the\n> \tlast question from me has always been \"then why are you\n> \trunning 'git pull' in the first place. The next paragraph is\n> \tmy attempt to extend my imagination a bit, stepping outside\n> \tthat reaction.\n"},{"id":"226843","messageId":"CAEBDL5VfHObeWZWvj0bnv5x+QF1_DACdU+Ehds6fHUioziHWrQ@mail.gmail.com","threadId":"34821","inReplyTo":"xmqqr4d4jird.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"John Szakmeister","fromEmail":"john@szakmeister.net","sentAt":"2013-09-05T11:01:03Z","receivedAt":"2013-09-05T11:01:03Z","isPatch":true,"sender":{"key":"john@szakmeister.net","avatar":"https://avatars.githubusercontent.com/u/448087?v=4"},"body":"On Wed, Sep 4, 2013 at 6:59 PM, Junio C Hamano wrote:\n[snip]\n> When \"git pull\" stops because what was fetched in FETCH_HEAD does\n> not fast-forward, then what did _you_ do (and with the knowledge you\n> currently have, what would you do)? In a single project, would you\n> choose to sometimes rebase and sometimes merge, and if so, what is\n> the choice depend on? \"When I am on these selected branches, I want\n> to merge, but on other branches I want to rebase?\"\n\nOur team isn't quite proficient enough yet to have a completely rebase\nworkflow... though we might have less of a problem if we did. So,\nseveral interesting points. Most of the time, `git pull` would be a\nfast-forward merge. We typically perform the merges of topic branches\nserver-side--we have a build server who checks to make sure the result\nwould be successful--and we just hit the big green button on the Merge\nbutton for the pull request (we use GitHub Enterprise at the moment).\n\nHowever, nearly as often, we just merge the branch locally because\nsomeone on the team is doing some manual testing, and it's just\nconvenient to finish the process on the command line. What\noccasionally happens is that you merge the topic locally, but someone\nelse has introduced a new commit to master. We try to preserve the\nmainline ordering of commits, so `git pull` doing a merge underneath\nthe hood is undesirable (it moves the newly introduced commit off to\nthe side). Rebasing your current master branch is not the answer\neither, because it picks up the commits introduced by the topic branch\nand rebases those to--at least with the -p option, and without it, the\nresults are just as bad). Instead, we want to unfold our work,\nfast-forward merge the upstream, and the replay our actions--namely\nremerge the topic branch. It often ends up translating to this:\n\n $ git reset --hard HEAD~1\n $ git merge --ff-only @{u}\n $ git merge topic\n $ git push\n\nSo what I really want isn't quite rebase. I'm not sure any of the\nproposed solutions would work. It'd be really nice to replay only the\nmainline commits, without affecting commits introduced from a topic\nbranch.\n\nAt any rate, this preserves the ordering we desire, but feels like a\nless than optimal process.\n\n-John\n"},{"id":"226844","messageId":"20130905113822.GF2582@serenity.lan","threadId":"34821","inReplyTo":"CAEBDL5VfHObeWZWvj0bnv5x+QF1_DACdU+Ehds6fHUioziHWrQ@mail.gmail.com","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2013-09-05T11:38:22Z","receivedAt":"2013-09-05T11:38:22Z","isPatch":true,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Thu, Sep 05, 2013 at 07:01:03AM -0400, John Szakmeister wrote:\n> On Wed, Sep 4, 2013 at 6:59 PM, Junio C Hamano wrote:\n> [snip]\n> > When \"git pull\" stops because what was fetched in FETCH_HEAD does\n> > not fast-forward, then what did _you_ do (and with the knowledge you\n> > currently have, what would you do)? In a single project, would you\n> > choose to sometimes rebase and sometimes merge, and if so, what is\n> > the choice depend on? \"When I am on these selected branches, I want\n> > to merge, but on other branches I want to rebase?\"\n> \n> Our team isn't quite proficient enough yet to have a completely rebase\n> workflow... though we might have less of a problem if we did. So,\n> several interesting points. Most of the time, `git pull` would be a\n> fast-forward merge. We typically perform the merges of topic branches\n> server-side--we have a build server who checks to make sure the result\n> would be successful--and we just hit the big green button on the Merge\n> button for the pull request (we use GitHub Enterprise at the moment).\n> \n> However, nearly as often, we just merge the branch locally because\n> someone on the team is doing some manual testing, and it's just\n> convenient to finish the process on the command line. What\n> occasionally happens is that you merge the topic locally, but someone\n> else has introduced a new commit to master. We try to preserve the\n> mainline ordering of commits, so `git pull` doing a merge underneath\n> the hood is undesirable (it moves the newly introduced commit off to\n> the side). Rebasing your current master branch is not the answer\n> either, because it picks up the commits introduced by the topic branch\n> and rebases those to--at least with the -p option, and without it, the\n> results are just as bad). Instead, we want to unfold our work,\n> fast-forward merge the upstream, and the replay our actions--namely\n> remerge the topic branch. It often ends up translating to this:\n> \n> $ git reset --hard HEAD~1\n> $ git merge --ff-only @{u}\n> $ git merge topic\n> $ git push\n> \n> So what I really want isn't quite rebase. I'm not sure any of the\n> proposed solutions would work. It'd be really nice to replay only the\n> mainline commits, without affecting commits introduced from a topic\n> branch.\n\nDoes \"git rebase --preserve-merges\" do what you want here?\n"},{"id":"226845","messageId":"CAEBDL5U2Y-dxtGyDTW+C-SseSpuF40BNMW3oZDnfzRx8KxG7fA@mail.gmail.com","threadId":"34821","inReplyTo":"20130905113822.GF2582@serenity.lan","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"John Szakmeister","fromEmail":"john@szakmeister.net","sentAt":"2013-09-05T12:37:20Z","receivedAt":"2013-09-05T12:37:20Z","isPatch":true,"sender":{"key":"john@szakmeister.net","avatar":"https://avatars.githubusercontent.com/u/448087?v=4"},"body":"On Thu, Sep 5, 2013 at 7:38 AM, John Keeping wrote:\n> On Thu, Sep 05, 2013 at 07:01:03AM -0400, John Szakmeister wrote:\n[snip]\n>> So what I really want isn't quite rebase. I'm not sure any of the\n>> proposed solutions would work. It'd be really nice to replay only the\n>> mainline commits, without affecting commits introduced from a topic\n>> branch.\n>\n> Does \"git rebase --preserve-merges\" do what you want here?\n\nNo, unfortunately, it does not. If the topic branch was not based on\nthe current tip of master, \"git rebase --preserve-merges\" will rebase\nthe commits of the topic branch as well. So this:\n\n Q -- R -- S (topic)\n / \\\n A -- B ------- D (master)\n\nWill become this after \"git rebase --preserve-merges @{u}\":\n\n Q' -- R' -- S' (topic')\n / \\\n A -- B -- C -------------- D' (master)\n\nIt's unfortunate for a couple of reasons. First, we don't want Q, R,\nand S rebased--we just want the merge replayed. Secondly, it gets\nmore confusing because Q, R, and S were rebased, but the topic branch\nwasn't actually touched. So topic still contains Q, R, and S, but\nmaster now contains Q', R', and S'. What we actually want is:\n\n Q -- R -- S (topic)\n / \\\n A -- B -- C -- D' (master)\n\nHTH!\n\n-John\n"},{"id":"226849","messageId":"rmi8uzbz96g.fsf@fnord.ir.bbn.com","threadId":"34821","inReplyTo":"xmqqa9jso69u.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"Greg Troxel","fromEmail":"gdt@ir.bbn.com","sentAt":"2013-09-05T13:31:51Z","receivedAt":"2013-09-05T13:31:51Z","isPatch":true,"sender":{"key":"gdt@ir.bbn.com","avatar":null},"body":"\nJunio C Hamano writes:\n\n> Peff already covered (1)---it is highly doubtful that a merge is\n> \"almost always wrong\". In fact, if that _were_ the case, we should\n> simply be defaulting to rebase, not failing the command and asking\n> between merge and rebase like jc/pull-training-wheel topic did.\n>\n> We simply do not know what the user wants, as it heavily depends on\n> the project, so we ask the user to choose one (and stick to it).\n\nFrom my experience leading the first large project using git at BBN,\nevolving a workflow (most work on topic branches, which are rebased,\nbanning 'git pull'-created merge commits, and explicit merge commits to\npreserve --first-parent, basically), and seeing many people struggle to\nlearn all this, my take is that a user who does not understand non-ff\nmerge vs ff-merge vs rebase will end up doing the wrong thing. So two\nthoughts:\n\n In the glorious future, perhaps git could have a way to express a\n machine-parseable representation of the workflow and rules for a repo,\n so that these choices could be made accordingly.\n\n In the current world, I think it makes sense to error out when there\n are multiple reasonable choices depending on workflow.\n\nOne of my team members, Richard Hansen, has argued to us that 'git pull'\nis harmful, essentially because it creates non-ff merges sometimes,\nwhile our rules say those should be rebased out. So we use\n\n[alias]\n\tup = !git remote update -p && git merge --ff-only @{u}\n\nwhich acts like pull if ff merge works, and otherwise errors out.\n\nI think the key question is: can a user who doesn't really understand\nthe implications of ff vs non-ff merges and the local workflow rules\nactually function ok, or do they need to stop and go back and\nunderstand. I'm in the \"you just have to take the time to understand\"\ncamp, which led to us having a semi-custom syllabus from github training\ncovering rebase, explicit vs ff merges and the consequences for\nfirst-parent history, etc.\n\nTherefore, I think \"git pull\" should do the update (perhaps of just the\nremote corresponding to @{u}, perhaps without -p) and a --ff-only merge,\nabsent a configuration asking for non-ff merge or rebase. (Arguably, an\nff merge is a degenerate case of rebase and also of the ff/non-ff merge,\nso it's safe with either policy.)\n\nGreg\n"},{"id":"226853","messageId":"5228A14B.3000804@bbn.com","threadId":"34821","inReplyTo":"xmqqr4d4jird.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"Richard Hansen","fromEmail":"rhansen@bbn.com","sentAt":"2013-09-05T15:20:43Z","receivedAt":"2013-09-05T15:20:43Z","isPatch":true,"sender":{"key":"rhansen@rhansen.org","avatar":null},"body":"On 2013-09-04 18:59, Junio C Hamano wrote:\n> \"Philip Oakley\" writes:\n> \n>> From: \"Junio C Hamano\" \n>>> John Keeping writes:\n>>>\n>>>> I think there are two distinct uses for pull, which boil down to:\n>>>>\n>>>> (1) git pull\n>>> ...\n>>> Peff already covered (1)---it is highly doubtful that a merge is\n>>> \"almost always wrong\". In fact, if that _were_ the case, we should\n>>> simply be defaulting to rebase, not failing the command and asking\n>>> between merge and rebase like jc/pull-training-wheel topic did.\n>>>\n>>> We simply do not know what the user wants, as it heavily depends on\n>>> the project, so we ask the user to choose one (and stick to it).\n>>\n>> We only offer a limited list. It won't be sufficient for all use\n>> cases. It wasn't for me.\n> \n> Very interesting. Tell us more.\n\nI'm a bit late to the discussion, but I wanted to chime in. I detest\n'git pull' and discourage everyone I meet from using it. See:\n\nfor my reasons.\n\nInstead, I encourage people to do this:\n\n git config --global alias.up '!git remote update -p; git merge\n--ff-only @{u}'\n\nand tell them to run 'git up' whenever they would be tempted to use a\nplain 'git pull'.\n\nI usually work with a central repository with topic branches. I follow\nthis rule of thumb:\n * When merging a \"same-named\" branch (e.g., origin/foo into foo, foo\n into origin/foo), it should always be a fast-forward. This may\n require rebasing.\n * When merging a \"differently-named\" branch (e.g., feature.xyz into\n master), it should never be a fast-forward.\n\nIn distributed workflows, I think of 'git pull \n' as merging a differently-named branch (I wouldn't be\nmerging if they hadn't told me that a separate feature they were working\non is complete), so I generally want the merge commit. But when I do a\n'git pull' without extra arguments, I'm updating a same-named branch so\nI never want a merge.\n\nWhen merging a differently-named branch, I prefer the merge --no-ff to\nbe preceded by a rebase to get a nice, pretty graph:\n\n * merge feature.xyz <- master\n |\\\n | * xyz part 3/3\n | * xyz part 2/3\n | * xyz part 1/3\n |/\n * merge feature.foo\n |\\\n | * foo part 2/2\n | * foo part 1/2\n |/\n * merge feature.bar\n |\\\n ...\n\nThe explicit merge has several benefits:\n * It clearly communicates to others that the feature is done.\n * It makes it easier to revert the entire feature by reverting the\n merge if necessary.\n * It allows our continuous integration tool to skip over the\n work-in-progress commits and test only complete features.\n * It makes it easier to review the entire feature in one diff.\n * 'git log --first-parent' shows a high-level summary of the changes\n over time, while a normal 'git log' shows the details.\n\n> \n> When \"git pull\" stops because what was fetched in FETCH_HEAD does\n> not fast-forward, then what did _you_ do (and with the knowledge you\n> currently have, what would you do)?\n\nI stop and review what's going on, then make a decision:\n * usually it's a rebase\n * sometimes it's a rebase --onto (because the branch was\n force-updated to undo a particularly bad commit)\n * sometimes it's a rebase -p (because there's an explicit merge of a\n different branch that I want to keep)\n * sometimes it's a reset --hard (my changes were made obsolete by a\n different upstream change)\n * sometimes it's a merge\n * sometimes I do nothing. This is a fairly regular pattern: I'm in\n the middle of working on something that I know will conflict with\n some changes that were just pushed upstream, and I want to finish\n my changes before starting the rebase. My collaborator contacts me\n and asks, \"Would you take a look at the changes I just pushed?\" If\n I type 'git pull' out of habit to get the commits, then I'll make a\n mess of my work-in-progress work tree. If I type 'git up' out of\n habit, then the merge --ff-only will fail as expected and I can\n quickly review the commits without messing with my work tree or\n HEAD.\n\nEven if I always rebase or always merge, I want to briefly review what\nchanged in the remote branch *before* I start the rebase. This helps me\nunderstand the conflicts I might encounter.\n\nThus, ff-only always works for me. I might have to type a second merge\nor rebase command, but that's OK -- it gives me an opportunity to think\nabout what I want first. Non-ff merges are rare enough that the\ninterruption isn't annoying at all.\n\n> In a single project, would you\n> choose to sometimes rebase and sometimes merge, and if so, what is\n> the choice depend on? \"When I am on these selected branches, I want\n> to merge, but on other branches I want to rebase?\"\n\nMy choice depends on the circumstances of the divergence. It's never as\nsimple as branch X always has this policy while branch Y has that policy.\n\n> Are there cases where you do not want to either rebase nor merge?\n> If so what do you want to do after \"git pull\" fetches from the other\n> side? Nothing?\n> \n> \tSide note: a knee-jerk response to a \"yes\" answer to the\n> \tlast question from me has always been \"then why are you\n> \trunning 'git pull' in the first place.\n\nHabit/muscle memory/I'm tired and not thinking 100% clearly.\n\n-Richard\n"},{"id":"226875","messageId":"xmqqd2onhyay.fsf@gitster.dls.corp.google.com","threadId":"34821","inReplyTo":"20130905080606.GE2582@serenity.lan","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-09-05T19:18:45Z","receivedAt":"2013-09-05T19:18:45Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"John Keeping writes:\n\n> On Wed, Sep 04, 2013 at 03:59:18PM -0700, Junio C Hamano wrote:\n>> Are there cases where you do not want to either rebase nor merge?\n>> If so what do you want to do after \"git pull\" fetches from the other\n>> side? Nothing?\n>\n> One other thing that I can see being useful occasionally is:\n>\n> git rebase @{u}@{1} --onto @{u}\n>\n> which allows local commits to be replayed onto a rewritten upstream\n> branch.\n\nSure, that would make sense.\n\nI somehow thought that rebase by default looked in the reflog to do\nexactly that. Perhaps I am not remembering correctly.\n"},{"id":"226876","messageId":"20130905192646.GG2582@serenity.lan","threadId":"34821","inReplyTo":"xmqqd2onhyay.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2013-09-05T19:26:47Z","receivedAt":"2013-09-05T19:26:47Z","isPatch":true,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Thu, Sep 05, 2013 at 12:18:45PM -0700, Junio C Hamano wrote:\n> John Keeping writes:\n> \n> > On Wed, Sep 04, 2013 at 03:59:18PM -0700, Junio C Hamano wrote:\n> >> Are there cases where you do not want to either rebase nor merge?\n> >> If so what do you want to do after \"git pull\" fetches from the other\n> >> side? Nothing?\n> >\n> > One other thing that I can see being useful occasionally is:\n> >\n> > git rebase @{u}@{1} --onto @{u}\n> >\n> > which allows local commits to be replayed onto a rewritten upstream\n> > branch.\n> \n> Sure, that would make sense.\n> \n> I somehow thought that rebase by default looked in the reflog to do\n> exactly that. Perhaps I am not remembering correctly.\n\nIt just does @{upstream} by default, which tends to get messy if the\nupstream has been rewritten.\n"},{"id":"226884","messageId":"BC4EB62C5077409384A225ECD96D04E1@PhilipOakley","threadId":"34821","inReplyTo":"xmqqr4d4jird.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-09-05T21:30:34Z","receivedAt":"2013-09-05T21:30:34Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Junio C Hamano\" \n> \"Philip Oakley\" writes:\n>\n>> From: \"Junio C Hamano\" \n>>> John Keeping writes:\n>>>\n>>>> I think there are two distinct uses for pull, which boil down to:\n>>>>\n>>>> (1) git pull\n>>> ...\n>>> Peff already covered (1)---it is highly doubtful that a merge is\n>>> \"almost always wrong\". In fact, if that _were_ the case, we should\n>>> simply be defaulting to rebase, not failing the command and asking\n>>> between merge and rebase like jc/pull-training-wheel topic did.\n>>>\n>>> We simply do not know what the user wants, as it heavily depends on\n>>> the project, so we ask the user to choose one (and stick to it).\n>>\n>> We only offer a limited list. It won't be sufficient for all use\n>> cases. It wasn't for me.\n>\n> Very interesting. Tell us more.\n>\nWhat I do now is avoid Pull because of the hassle of fixing anything\nthat may have gone wrong.\n\nInstead I now use a 'git fetch', followed by a 'push . (+etc:etc)' once \nI understand what I've got, or what I need to do different if wasn't a \nsimple fast forward 'pull'.\n\n> When \"git pull\" stops because what was fetched in FETCH_HEAD does\n> not fast-forward, then what did _you_ do (and with the knowledge you\n> currently have, what would you do)? In a single project, would you\n> choose to sometimes rebase and sometimes merge, and if so, what is\n> the choice depend on? \"When I am on these selected branches, I want\n> to merge, but on other branches I want to rebase?\"\n>\n\nIn my case I have two home machines (main Windows machine and an \noccasional Linux laptop, though not directly networked together) and \ngithub as my level group, and have MSysGit and git/git (on github) as \ntrue upstreams, though they haven't been named that way [Aside: we are \nshort of a good name for one's 'across-stream server' that one uses for \nbackup/transfer such as github].\n\nI general now use a forced update to bring my local machine up to date \nrelative to whatever is upstream or on my across stream server, such as \nwhen transferring development from one machine to the other (where \noverwrite is the desired action) - e.g. when testing on the Linux laptop \nand a few corrections, before patch preparation on the Windows machine \n(different levels of familiarity).\n\nI occasionally will need to rebase my topic onto an updated git/master \nor git/pu if it is to be submitted upstream (patches to the list) or if \nupstream has moved, though I want to choose where I will rebase the \ntopic onto. I don't need merging in that scenario, as I see those via \nyour git repo ;-)\n\nIt's not clear to me that a single default that uses a merge or rebase, \nwithout a 'stop if' criteria would be of any help in my situation.\n\nMy thoughts are that the options on a fetch-pull are for the branch to \nbe:\n* Overwritte (--force) (i.e. a conflict scenario)\n* Stop if not-ff (conflict scenario, this patch series)\n* rebase existing onto tracked [not a conflict in terms of initiation]\n* merge existing into tracked [not a conflict in terms of initiation]\n* fast-forward (bring tracked onto existing) [desired]\n\nPhilip\n"},{"id":"226894","messageId":"xmqq7geug7oy.fsf@gitster.dls.corp.google.com","threadId":"34821","inReplyTo":"xmqqr4d4jird.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-09-05T23:38:53Z","receivedAt":"2013-09-05T23:38:53Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> I can imagine users might want to say \"when I am on these small\n> number of branches, I want to merge (or rebase), but when I am on\n> other, majority of my branches, because they are private, unfinished\n> and unpublished work, please stop me from accidentally messing their\n> histories with changes from upstream or anywhere else for that\n> matter\". If that is the issue you are trying to raise, because\n> there is no\n>\n> \t[pull]\n> \trebase = fail\n> \t[branch \"master\"]\n> \trebase = yes\n>\n> to force \"git pull\" to fail by default on any branch while allowing\n> it to rebase (or merge, for that matter) only on a few selected\n> branches, we fall a bit short.\n>\n> Which can be solved by adding the above \"fail\" option, and then\n> renaming them to \"pull.integrate\" and \"branch..integrate\" to\n> clarify what these variables are about (it is no longer \"do you\n> rebase or not---if you choose not to rebase, by definition you are\n> going to merge\", as there is a third choice to \"fail\"), while\n> retaining \"pull.rebase\" and \"branch..rebase\" as a deprecated\n> synonym.\n\nThe first step of such an enhancement may look like this patch. It\nintroduces \"pull.integrate\" and \"branch..integrate\" that will\neventually deprecate \"*.rebase\", but at this step only supports\nvalues \"rebase\" and \"merge\" (i.e. no \"fail\" yet).\n\nThe steps after this change would be to\n\n * Enhance addition to t5520 made by 949e0d8e (pull: require choice\n between rebase/merge on non-fast-forward pull, 2013-06-27) to\n make sure that setting pull.integrate and branch..integrate\n will squelch the safety added by that patch;\n\n * Teach \"branch.c\" to set \"branch..integrate\" either instead\n of or in addition to \"branch..rebase\", and adjust tests\n that expect to see \"branch..rebase\" to expect to see that\n \"branch..integrate\" is set to \"rebase\";\n\n * Add \"fail\" to the set of valid values for \"*.integrate\", and teach\n \"git pull\" honor it; and\n\n * Update builtin/remote.c to show cases where branch..integrate\n is set to \"fail\" in some different way.\n\nI do not plan to do these follow-up steps myself soonish (hint,\nhint).\n\n builtin/remote.c | 12 ++++++++++--\n git-pull.sh | 60 +++++++++++++++++++++++++++++++++++++-------------------\n 2 files changed, 50 insertions(+), 22 deletions(-)\n\ndiff --git a/builtin/remote.c b/builtin/remote.c\nindex 5e54d36..d3b6d0b5 100644\n--- a/builtin/remote.c\n+++ b/builtin/remote.c\n@@ -274,7 +274,7 @@ static int config_read_branches(const char *key, const char *value, void *cb)\n \t\tchar *name;\n \t\tstruct string_list_item *item;\n \t\tstruct branch_info *info;\n-\t\tenum { REMOTE, MERGE, REBASE } type;\n+\t\tenum { REMOTE, MERGE, REBASE, INTEGRATE } type;\n \n \t\tkey += 7;\n \t\tif (!postfixcmp(key, \".remote\")) {\n@@ -286,6 +286,9 @@ static int config_read_branches(const char *key, const char *value, void *cb)\n \t\t} else if (!postfixcmp(key, \".rebase\")) {\n \t\t\tname = xstrndup(key, strlen(key) - 7);\n \t\t\ttype = REBASE;\n+\t\t} else if (!postfixcmp(key, \".integrate\")) {\n+\t\t\tname = xstrndup(key, strlen(key) - 10);\n+\t\t\ttype = INTEGRATE;\n \t\t} else\n \t\t\treturn 0;\n \n@@ -309,8 +312,13 @@ static int config_read_branches(const char *key, const char *value, void *cb)\n \t\t\t\tspace = strchr(value, ' ');\n \t\t\t}\n \t\t\tstring_list_append(&info->merge, xstrdup(value));\n-\t\t} else\n+\t\t} else if (type == REBASE) {\n \t\t\tinfo->rebase = git_config_bool(orig_key, value);\n+\t\t} else if (type == INTEGRATE) {\n+\t\t\tif (!value)\n+\t\t\t\treturn config_error_nonbool(orig_key);\n+\t\t\tinfo->rebase = !strcmp(value, \"rebase\");\n+\t\t}\n \t}\n \treturn 0;\n }\ndiff --git a/git-pull.sh b/git-pull.sh\nindex 88c198f..5c557b7 100755\n--- a/git-pull.sh\n+++ b/git-pull.sh\n@@ -45,16 +45,34 @@ merge_args= edit=\n curr_branch=$(git symbolic-ref -q HEAD)\n curr_branch_short=\"${curr_branch#refs/heads/}\"\n \n-# See if we are configured to rebase by default.\n-# The value $rebase is, throughout the main part of the code:\n+# See what we are configured to do by default.\n+# The value $integration is, throughout the main part of the code:\n # (empty) - the user did not have any preference\n-# true - the user told us to integrate by rebasing\n-# false - the user told us to integrate by merging\n-rebase=$(git config --bool branch.$curr_branch_short.rebase)\n-if test -z \"$rebase\"\n-then\n-\trebase=$(git config --bool pull.rebase)\n-fi\n+# rebase - the user told us to integrate by rebasing\n+# merge - the user told us to integrate by merging\n+\n+integration=\n+\n+set_integration () {\n+\tintegration=$(git config branch.$curr_branch_short.integrate)\n+\ttest -n \"$integration\" && return\n+\n+\tcase \"$(git config --bool branch.$curr_branch_short.rebase)\" in\n+\ttrue)\tintegration=rebase ;;\n+\tfalse)\tintegration=merge ;;\n+\tesac\n+\ttest -n \"$integration\" && return\n+\n+\tintegration=$(git config pull.integrate)\n+\ttest -n \"$integration\" && return\n+\n+\tcase \"$(git config --bool pull.rebase)\" in\n+\ttrue)\tintegration=rebase ;;\n+\tfalse)\tintegration=merge ;;\n+\tesac\n+}\n+\n+set_integration\n \n dry_run=\n while :\n@@ -119,11 +137,11 @@ do\n \t\tmerge_args=\"$merge_args$xx \"\n \t\t;;\n \t-r|--r|--re|--reb|--reba|--rebas|--rebase)\n-\t\trebase=true\n+\t\tintegration=rebase\n \t\t;;\n \t--no-r|--no-re|--no-reb|--no-reba|--no-rebas|--no-rebase|\\\n \t-m|--m|--me|--mer|--merg|--merge)\n-\t\trebase=false\n+\t\tintegration=merge\n \t\t;;\n \t--recurse-submodules)\n \t\trecurse_submodules=--recurse-submodules\n@@ -166,7 +184,7 @@ error_on_no_merge_candidates () {\n \t\tesac\n \tdone\n \n-\tif test true = \"$rebase\"\n+\tif test \"$integration\" = rebase\n \tthen\n \t\top_type=rebase\n \t\top_prep=against\n@@ -180,7 +198,8 @@ error_on_no_merge_candidates () {\n \tremote=$(git config \"branch.$curr_branch.remote\")\n \n \tif [ $# -gt 1 ]; then\n-\t\tif [ \"$rebase\" = true ]; then\n+\t\tif test \"$integration\" = rebase\n+\t\tthen\n \t\t\tprintf \"There is no candidate for rebasing against \"\n \t\telse\n \t\t\tprintf \"There are no candidates for merging \"\n@@ -203,7 +222,8 @@ error_on_no_merge_candidates () {\n \texit 1\n }\n \n-test true = \"$rebase\" && {\n+if test \"$integration\" = rebase\n+then\n \tif ! git rev-parse -q --verify HEAD >/dev/null\n \tthen\n \t\t# On an unborn branch\n@@ -227,7 +247,7 @@ test true = \"$rebase\" && {\n \t\t\tbreak\n \t\tfi\n \tdone\n-}\n+fi\n \n orig_head=$(git rev-parse -q --verify HEAD)\n git fetch $verbosity $progress $dry_run $recurse_submodules --update-head-ok \"$@\" || exit 1\n@@ -269,7 +289,7 @@ case \"$merge_head\" in\n \tthen\n \t\tdie \"$(gettext \"Cannot merge multiple branches into empty head\")\"\n \tfi\n-\tif test true = \"$rebase\"\n+\tif test \"$integration\" = rebase\n \tthen\n \t\tdie \"$(gettext \"Cannot rebase onto multiple branches\")\"\n \tfi\n@@ -279,7 +299,7 @@ case \"$merge_head\" in\n \t# trigger this check when we will say \"fast-forward\" or \"already\n \t# up-to-date\".\n \tmerge_head=${merge_head% }\n-\tif test -z \"$rebase$no_ff$ff_only${squash#--no-squash}\" &&\n+\tif test -z \"$integration$no_ff$ff_only${squash#--no-squash}\" &&\n \t\ttest -n \"$orig_head\" &&\n \t\ttest $# = 0 &&\n \t\t! git merge-base --is-ancestor \"$orig_head\" \"$merge_head\" &&\n@@ -311,7 +331,7 @@ then\n \texit\n fi\n \n-if test true = \"$rebase\"\n+if test \"$integration\" = rebase\n then\n \to=$(git show-branch --merge-base $curr_branch $merge_head $oldremoteref)\n \tif test \"$oldremoteref\" = \"$o\"\n@@ -321,8 +341,8 @@ then\n fi\n \n merge_name=$(git fmt-merge-msg $log_arg <\"$GIT_DIR/FETCH_HEAD\") || exit\n-case \"$rebase\" in\n-true)\n+case \"$integration\" in\n+rebase)\n \teval=\"git-rebase $diffstat $strategy_args $merge_args $verbosity\"\n \teval=\"$eval --onto $merge_head ${oldremoteref:-$merge_head}\"\n \t;;\n"},{"id":"226896","messageId":"xmqqzjrqest8.fsf@gitster.dls.corp.google.com","threadId":"34821","inReplyTo":"BC4EB62C5077409384A225ECD96D04E1@PhilipOakley","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-09-05T23:45:39Z","receivedAt":"2013-09-05T23:45:39Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Philip Oakley\" writes:\n\n> It's not clear to me that a single default that uses a merge or\n> rebase, without a 'stop if' criteria would be of any help in my\n> situation.\n>\n> My thoughts are that the options on a fetch-pull are for the branch to\n> be:\n> * Overwritte (--force) (i.e. a conflict scenario)\n> * Stop if not-ff (conflict scenario, this patch series)\n> * rebase existing onto tracked [not a conflict in terms of initiation]\n> * merge existing into tracked [not a conflict in terms of initiation]\n> * fast-forward (bring tracked onto existing) [desired]\n\nIn short, it sounds to me like that the answer to my question is\n\"what I do depends too much on what I did on my other machine that\nis not even directly connected to this matchine, so there is no way\nto formulate it as a concrete workflow---I need to inspect what I\nget from the central repository and decide the next step anyway, so\nI just want 'git pull' not to do anything\".\n\nAmong the things that were suggested so far (the 'pull' update that\nhas been cooking in the 'next' branch, Felipe's tightening to apply\nthe same logic to 'git pull $there $that' as well as 'git pull', and\nbeing able to set \"pull.rebase = fail\" and renaming the variable to\nsomething like \"pull.integrate = fail\"), only the last one seems to\nbe the solution to your particular case. The other two would not\nhelp such an ad-hoc (non)workflow very much either way.\n\nAm I reading you correctly? If so, I sent out the first (or zeroth)\nstep to add something like that separately.\n"},{"id":"226990","messageId":"20130906214138.GA7470@google.com","threadId":"34821","inReplyTo":"20130905192646.GG2582@serenity.lan","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-09-06T21:41:38Z","receivedAt":"2013-09-06T21:41:38Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"John Keeping wrote:\n> On Thu, Sep 05, 2013 at 12:18:45PM -0700, Junio C Hamano wrote:\n\n>> I somehow thought that rebase by default looked in the reflog to do\n>> exactly that. Perhaps I am not remembering correctly.\n>\n> It just does @{upstream} by default, which tends to get messy if the\n> upstream has been rewritten.\n\nMaybe Junio is thinking of 'git pull --rebase', which walks the reflog\nuntil it finds an ancestor of the current branch and uses that as the\n parameter to rebase.\n"},{"id":"226997","messageId":"xmqq1u51wqbi.fsf@gitster.dls.corp.google.com","threadId":"34821","inReplyTo":"20130906214138.GA7470@google.com","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-09-06T22:14:25Z","receivedAt":"2013-09-06T22:14:25Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder writes:\n\n> John Keeping wrote:\n>> On Thu, Sep 05, 2013 at 12:18:45PM -0700, Junio C Hamano wrote:\n>\n>>> I somehow thought that rebase by default looked in the reflog to do\n>>> exactly that. Perhaps I am not remembering correctly.\n>>\n>> It just does @{upstream} by default, which tends to get messy if the\n>> upstream has been rewritten.\n>\n> Maybe Junio is thinking of 'git pull --rebase', which walks the reflog\n> until it finds an ancestor of the current branch and uses that as the\n> parameter to rebase.\n\nYou're right.\n\nIt makes me wonder why we did that one inside pull and not in\nrebase, though.\n"},{"id":"227019","messageId":"20130907110745.GH2582@serenity.lan","threadId":"34821","inReplyTo":"xmqq1u51wqbi.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2013-09-07T11:07:45Z","receivedAt":"2013-09-07T11:07:45Z","isPatch":true,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Fri, Sep 06, 2013 at 03:14:25PM -0700, Junio C Hamano wrote:\n> Jonathan Nieder writes:\n> \n> > John Keeping wrote:\n> >> On Thu, Sep 05, 2013 at 12:18:45PM -0700, Junio C Hamano wrote:\n> >\n> >>> I somehow thought that rebase by default looked in the reflog to do\n> >>> exactly that. Perhaps I am not remembering correctly.\n> >>\n> >> It just does @{upstream} by default, which tends to get messy if the\n> >> upstream has been rewritten.\n> >\n> > Maybe Junio is thinking of 'git pull --rebase', which walks the reflog\n> > until it finds an ancestor of the current branch and uses that as the\n> > parameter to rebase.\n> \n> You're right.\n> \n> It makes me wonder why we did that one inside pull and not in\n> rebase, though.\n\nI'd never realised \"pull --rebase\" does that - it's exactly what I want\nsometimes and I normally do fetch followed by rebase to get more control\nover the process.\n\nPerhaps we should do something like this (with added tests and\ndocumentation)?\n\n-- >8 --\nSubject: [PATCH] rebase: use reflog to find common base with upstream\n\nSigned-off-by: John Keeping \n---\n git-rebase.sh | 8 ++++++++\n 1 file changed, 8 insertions(+)\n\ndiff --git a/git-rebase.sh b/git-rebase.sh\nindex 8d7659a..5e3013d 100755\n--- a/git-rebase.sh\n+++ b/git-rebase.sh\n@@ -428,6 +428,14 @@ then\n \t\t\terror_on_missing_default_upstream \"rebase\" \"rebase\" \\\n \t\t\t\t\"against\" \"git rebase \"\n \t\tfi\n+\t\tfor reflog in $(git rev-list -g \"$upstream_name\" 2>/dev/null)\n+\t\tdo\n+\t\t\tif test \"$reflog\" = \"$(git merge-base \"$reflog\" HEAD)\"\n+\t\t\tthen\n+\t\t\t\tupstream_name=$reflog\n+\t\t\t\tbreak\n+\t\t\tfi\n+\t\tdone\n \t\t;;\n \t*)\tupstream_name=\"$1\"\n \t\tshift\n-- \n1.8.4.239.g2332621\n"},{"id":"227049","messageId":"CAMP44s1Rb2WKGD-QfNh055099R+9FHv9W8TA8Gfjp=qZh_7p7Q@mail.gmail.com","threadId":"34821","inReplyTo":"20130905080606.GE2582@serenity.lan","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-09-08T02:34:51Z","receivedAt":"2013-09-08T02:34:51Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Sep 5, 2013 at 3:06 AM, John Keeping wrote:\n> On Wed, Sep 04, 2013 at 03:59:18PM -0700, Junio C Hamano wrote:\n>> Are there cases where you do not want to either rebase nor merge?\n>> If so what do you want to do after \"git pull\" fetches from the other\n>> side? Nothing?\n>\n> One other thing that I can see being useful occasionally is:\n>\n> git rebase @{u}@{1} --onto @{u}\n>\n> which allows local commits to be replayed onto a rewritten upstream\n> branch.\n>\n> Although I agree with your side note below that people doing this may be\n> better off fetching and then updating their local branch, particularly\n> if @{1} is not the correct reflog entry for the upstream when they\n> created the branch.\n\nThat's why after recognizing the fact the you can't find the branch\npoint of a branch in Git, I decided to write patches to support the\n@{tail} shorthand, which is basically the point where the branch was\ncreated, or rebased to:\n\nhttps://github.com/felipec/git/commits/fc/base\n\nAnd if 'git rebase' was fixed to ignore the commits already in the\nrebased onto branch, almost always what you would want to do is 'git\nrebase @{tail} --onto @{upstream}'.\n\n-- \nFelipe Contreras\n"},{"id":"227050","messageId":"CAMP44s2e59ZME4sVP1ZD7geMDKGbcY4ZKiRTR2z1A4gviQvK6g@mail.gmail.com","threadId":"34821","inReplyTo":"xmqq1u51wqbi.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-09-08T02:36:58Z","receivedAt":"2013-09-08T02:36:58Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Fri, Sep 6, 2013 at 5:14 PM, Junio C Hamano wrote:\n> Jonathan Nieder writes:\n>\n>> John Keeping wrote:\n>>> On Thu, Sep 05, 2013 at 12:18:45PM -0700, Junio C Hamano wrote:\n>>\n>>>> I somehow thought that rebase by default looked in the reflog to do\n>>>> exactly that. Perhaps I am not remembering correctly.\n>>>\n>>> It just does @{upstream} by default, which tends to get messy if the\n>>> upstream has been rewritten.\n>>\n>> Maybe Junio is thinking of 'git pull --rebase', which walks the reflog\n>> until it finds an ancestor of the current branch and uses that as the\n>> parameter to rebase.\n>\n> You're right.\n>\n> It makes me wonder why we did that one inside pull and not in\n> rebase, though.\n\nBecause there's a huge difference between:\n\ngit rebase @{u}@{1} --onto @{u}\n\nAnd\n\ngit rebase @{u}\n\nI was in the process of fixing that, but you stopped me.\n\n-- \nFelipe Contreras\n"},{"id":"227051","messageId":"CAMP44s0kMbXvcJbWvJDu=8A5iOeH4fsMGUdT-ehXKNXiV1FQ1Q@mail.gmail.com","threadId":"34821","inReplyTo":"xmqqr4d4jird.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-09-08T02:41:00Z","receivedAt":"2013-09-08T02:41:00Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Wed, Sep 4, 2013 at 5:59 PM, Junio C Hamano wrote:\n\n> Which can be solved by adding the above \"fail\" option, and then\n> renaming them to \"pull.integrate\" and \"branch..integrate\" to\n> clarify what these variables are about (it is no longer \"do you\n> rebase or not---if you choose not to rebase, by definition you are\n> going to merge\", as there is a third choice to \"fail\"), while\n> retaining \"pull.rebase\" and \"branch..rebase\" as a deprecated\n> synonym.\n\nAll these names are completely unintuitive. First of all, why\n\"integrate\"? Integrate what to what? And then, why \"fail\"? Fail on\nwhat circumstances? Always?\n\nMy proposal that does:\n\n pull.mode = merge/rebase/merge-ff-only\n\nIs way more intuitive.\n\n-- \nFelipe Contreras\n"},{"id":"227053","messageId":"CAMP44s3Vaqe-POwQb30AGdarf=ObdPUay3QEMqxHV3NKiPAouA@mail.gmail.com","threadId":"34821","inReplyTo":"20130904092527.GB22348@sigill.intra.peff.net","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-09-08T02:52:16Z","receivedAt":"2013-09-08T02:52:16Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Wed, Sep 4, 2013 at 4:25 AM, Jeff King wrote:\n\n> The patch in jc/pull-training-wheel talks about annoying old timers, but\n> I think you may also be annoying clueless new users who simply want an\n> svn-like workflow without thinking too hard about it.\n\nHow? Subversion would complain if you have local changes when you do\n'svn pull', there's no notion of remotes, branches and merges are\nrare, and forget about rebases.\n\n>> > I do not think we know what we want is to affect \"git pull origin\".\n>>\n>> I consider \"git pull $remote\" to be an artifact of the way git-pull is\n>> implemented on top of git-fetch; perhaps I'm missing something but I\n>> can't see a scenario where this is useful.\n>\n> Imagine a workflow where each topic is in its own repository instead of\n> in its own branch inside a repository. Or where each developer has his\n> or her own repository, but everybody just works on the master branch of\n> their repository (or perhaps uses branches, but keeps master as a stable\n> base). Alice is the integration manager; Bob tells her that he has work\n> ready to integrate. She runs \"git pull ~bob/project\", which will merge\n> Bob's HEAD.\n\nThese integrators should know what they are doing, so they can do 'git\npull --merge', or better 'git config pull.mode merge', as Linus\nhimself suggested (or something like that).\n\nThe defaults should care most about the clueless users.\n\n-- \nFelipe Contreras\n"},{"id":"227061","messageId":"20130908041805.GB14019@sigill.intra.peff.net","threadId":"34821","inReplyTo":"CAMP44s3Vaqe-POwQb30AGdarf=ObdPUay3QEMqxHV3NKiPAouA@mail.gmail.com","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-09-08T04:18:05Z","receivedAt":"2013-09-08T04:18:05Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Sep 07, 2013 at 09:52:16PM -0500, Felipe Contreras wrote:\n\n> On Wed, Sep 4, 2013 at 4:25 AM, Jeff King wrote:\n> \n> > The patch in jc/pull-training-wheel talks about annoying old timers, but\n> > I think you may also be annoying clueless new users who simply want an\n> > svn-like workflow without thinking too hard about it.\n> \n> How? Subversion would complain if you have local changes when you do\n> 'svn pull', there's no notion of remotes, branches and merges are\n> rare, and forget about rebases.\n\nBy \"svn-like\", I mean the people whose workflow is:\n\n $ hack hack hack\n $ git commit\n $ git push ;# oops, somebody else pushed in the meantime\n $ git pull\n $ git push\n\nwithout using branches or worrying about the shape of history. I do not\nknow what you mean by \"svn pull\", since that command does not exist\n(unless you are talking about svk?). In subversion, that workflow would\nbe:\n\n $ hack hack hack\n $ svn commit ;# oops, somebody else committed in the meantime\n $ svn update\n $ svn commit\n\nThose people would now have to learn enough to choose between merge and\nrebase when running the \"git pull\".\n\nIt may be OK to say \"we do not care about that case, and it is a good\nthing that they learn enough to make the choice consciously.\" But I do\nthink they exist.\n\n> >> > I do not think we know what we want is to affect \"git pull origin\".\n> >>\n> >> I consider \"git pull $remote\" to be an artifact of the way git-pull is\n> >> implemented on top of git-fetch; perhaps I'm missing something but I\n> >> can't see a scenario where this is useful.\n> >\n> > Imagine a workflow where each topic is in its own repository instead of\n> > in its own branch inside a repository. Or where each developer has his\n> > or her own repository, but everybody just works on the master branch of\n> > their repository (or perhaps uses branches, but keeps master as a stable\n> > base). Alice is the integration manager; Bob tells her that he has work\n> > ready to integrate. She runs \"git pull ~bob/project\", which will merge\n> > Bob's HEAD.\n> \n> These integrators should know what they are doing, so they can do 'git\n> pull --merge', or better 'git config pull.mode merge', as Linus\n> himself suggested (or something like that).\n> \n> The defaults should care most about the clueless users.\n\nIn this part of the email you are quoting I was not intending to say\nanything about clueless users at all, nor even about what defaults there\nare. John indicated that he could not imagine a scenario of \"git pull\n$remote\", so I gave an example.\n\n-Peff\n"},{"id":"227063","messageId":"CAMP44s01LL2JCKzqa0Qc5MfBz9zfMXR4H8jZdauLOi-D0JVHpw@mail.gmail.com","threadId":"34821","inReplyTo":"20130908041805.GB14019@sigill.intra.peff.net","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-09-08T04:37:13Z","receivedAt":"2013-09-08T04:37:13Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sat, Sep 7, 2013 at 11:18 PM, Jeff King wrote:\n> On Sat, Sep 07, 2013 at 09:52:16PM -0500, Felipe Contreras wrote:\n>\n>> On Wed, Sep 4, 2013 at 4:25 AM, Jeff King wrote:\n>>\n>> > The patch in jc/pull-training-wheel talks about annoying old timers, but\n>> > I think you may also be annoying clueless new users who simply want an\n>> > svn-like workflow without thinking too hard about it.\n>>\n>> How? Subversion would complain if you have local changes when you do\n>> 'svn pull', there's no notion of remotes, branches and merges are\n>> rare, and forget about rebases.\n>\n> By \"svn-like\", I mean the people whose workflow is:\n>\n> $ hack hack hack\n> $ git commit\n> $ git push ;# oops, somebody else pushed in the meantime\n> $ git pull\n> $ git push\n\nBut that's not svn-like at all.\n\n> without using branches or worrying about the shape of history. I do not\n> know what you mean by \"svn pull\", since that command does not exist\n> (unless you are talking about svk?). In subversion, that workflow would\n> be:\n>\n> $ hack hack hack\n> $ svn commit ;# oops, somebody else committed in the meantime\n> $ svn update\n> $ svn commit\n>\n> Those people would now have to learn enough to choose between merge and\n> rebase when running the \"git pull\".\n\nBut that's only if they don't care about the shape of history. In my\nexperience the people that cling more to centralized VCS do not like\nmerges, so they rebase everything to make it a straight line. That is\nmuch more \"svn-like\".\n\nSo chances are they are already doing 'git pull --rebase' (or\nsimilar), so their workflow wouldn't be affected.\n\n> It may be OK to say \"we do not care about that case, and it is a good\n> thing that they learn enough to make the choice consciously.\" But I do\n> think they exist.\n\nYeah, I'm sure they exist, but they are a tiny minority compared to\nthe amount of people who don't actually understand what 'git pull' is\ndoing and do merges by mistake.\n\n-- \nFelipe Contreras\n"},{"id":"227064","messageId":"20130908044329.GA15087@sigill.intra.peff.net","threadId":"34821","inReplyTo":"CAMP44s01LL2JCKzqa0Qc5MfBz9zfMXR4H8jZdauLOi-D0JVHpw@mail.gmail.com","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-09-08T04:43:29Z","receivedAt":"2013-09-08T04:43:29Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Sep 07, 2013 at 11:37:13PM -0500, Felipe Contreras wrote:\n\n> > By \"svn-like\", I mean the people whose workflow is:\n> >\n> > $ hack hack hack\n> > $ git commit\n> > $ git push ;# oops, somebody else pushed in the meantime\n> > $ git pull\n> > $ git push\n> \n> But that's not svn-like at all.\n\nIt's not if you understand the difference between merge-then-commit and\ncommit-then-merge. But for a clueless user who has been told \"replace\nsvn commit\" with \"git commit && git push\" and replace \"svn update\" with\n\"git pull\", it is quite similar.\n\n> > Those people would now have to learn enough to choose between merge and\n> > rebase when running the \"git pull\".\n> \n> But that's only if they don't care about the shape of history. In my\n> experience the people that cling more to centralized VCS do not like\n> merges, so they rebase everything to make it a straight line. That is\n> much more \"svn-like\".\n> \n> So chances are they are already doing 'git pull --rebase' (or\n> similar), so their workflow wouldn't be affected.\n\nI think we are talking about two classes of users. People who truly\ndon't care about the shape of history will also not care about using\n\"git pull --rebase\", because the only reason to use it is to impact the\nshape of history.\n\nI agree there is also a set of people coming from the centralized vcs\nworld who want to keep a linear history.\n\n-Peff\n"},{"id":"227071","messageId":"CAMP44s3kow9dooPzK6iD8p2LAgt1mtFuaNsVhkJHrqe4D+8xLQ@mail.gmail.com","threadId":"34821","inReplyTo":"20130908044329.GA15087@sigill.intra.peff.net","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-09-08T05:09:34Z","receivedAt":"2013-09-08T05:09:34Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sat, Sep 7, 2013 at 11:43 PM, Jeff King wrote:\n> On Sat, Sep 07, 2013 at 11:37:13PM -0500, Felipe Contreras wrote:\n>\n>> > By \"svn-like\", I mean the people whose workflow is:\n>> >\n>> > $ hack hack hack\n>> > $ git commit\n>> > $ git push ;# oops, somebody else pushed in the meantime\n>> > $ git pull\n>> > $ git push\n>>\n>> But that's not svn-like at all.\n>\n> It's not if you understand the difference between merge-then-commit and\n> commit-then-merge. But for a clueless user who has been told \"replace\n> svn commit\" with \"git commit && git push\" and replace \"svn update\" with\n> \"git pull\", it is quite similar.\n\nWell, yeah, but if they are so clueless they have to be told what to\ndo, they can be told to do 'git pull --merge' instead, no?\n\n>> > Those people would now have to learn enough to choose between merge and\n>> > rebase when running the \"git pull\".\n>>\n>> But that's only if they don't care about the shape of history. In my\n>> experience the people that cling more to centralized VCS do not like\n>> merges, so they rebase everything to make it a straight line. That is\n>> much more \"svn-like\".\n>>\n>> So chances are they are already doing 'git pull --rebase' (or\n>> similar), so their workflow wouldn't be affected.\n>\n> I think we are talking about two classes of users. People who truly\n> don't care about the shape of history will also not care about using\n> \"git pull --rebase\", because the only reason to use it is to impact the\n> shape of history.\n>\n> I agree there is also a set of people coming from the centralized vcs\n> world who want to keep a linear history.\n\nYeah, and based on the evidence, one set of people is much much larger\nthan the other; the people that care what the history look like.\n\nEither way, we can start by making it a warning, and then an error,\nand if more people complain that they have to do 'git pull --merge'\nnow (I bet there won't be any), then you would be right, and we\nrevert. No problem.\n\n-- \nFelipe Contreras\n"},{"id":"227072","messageId":"20130908052107.GA15610@sigill.intra.peff.net","threadId":"34821","inReplyTo":"CAMP44s3kow9dooPzK6iD8p2LAgt1mtFuaNsVhkJHrqe4D+8xLQ@mail.gmail.com","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-09-08T05:21:07Z","receivedAt":"2013-09-08T05:21:07Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Sep 08, 2013 at 12:09:34AM -0500, Felipe Contreras wrote:\n\n> > It's not if you understand the difference between merge-then-commit and\n> > commit-then-merge. But for a clueless user who has been told \"replace\n> > svn commit\" with \"git commit && git push\" and replace \"svn update\" with\n> > \"git pull\", it is quite similar.\n> \n> Well, yeah, but if they are so clueless they have to be told what to\n> do, they can be told to do 'git pull --merge' instead, no?\n\nI think it's fine to tell them to do \"git pull --merge\". What I'd worry\nmore about is somebody who is suddenly presented with the choice between\n\"--rebase\" and \"--merge\" and doesn't know which to choose. We've created a\ncognitive load on the user, and even more load if they choose --rebase\nand don't quite understand what it means.\n\nThe current warning message in jc/pull-training-wheel is quite neutral\nbetween the two options. Perhaps we should lean more towards merging?\n\nI guess that works against John's case, though, which is clueless people\nworking on a project that _does_ care about the shape of history. At\nleast they would have to stop and think for a moment, though, which\nmight help (and maybe convince them to ask more clueful project\nmembers). I don't know.\n\n-Peff\n"},{"id":"227076","messageId":"CAMP44s3U2rJsqTj4cAOpY1ntum53bEy2cP5XRNaMu5vwnYVoww@mail.gmail.com","threadId":"34821","inReplyTo":"20130908052107.GA15610@sigill.intra.peff.net","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-09-08T06:17:42Z","receivedAt":"2013-09-08T06:17:42Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sun, Sep 8, 2013 at 12:21 AM, Jeff King wrote:\n> On Sun, Sep 08, 2013 at 12:09:34AM -0500, Felipe Contreras wrote:\n>\n>> > It's not if you understand the difference between merge-then-commit and\n>> > commit-then-merge. But for a clueless user who has been told \"replace\n>> > svn commit\" with \"git commit && git push\" and replace \"svn update\" with\n>> > \"git pull\", it is quite similar.\n>>\n>> Well, yeah, but if they are so clueless they have to be told what to\n>> do, they can be told to do 'git pull --merge' instead, no?\n>\n> I think it's fine to tell them to do \"git pull --merge\". What I'd worry\n> more about is somebody who is suddenly presented with the choice between\n> \"--rebase\" and \"--merge\" and doesn't know which to choose. We've created a\n> cognitive load on the user, and even more load if they choose --rebase\n> and don't quite understand what it means.\n\nIf that happens they will go back to the guy that told them to run\nthose commands.\n\nFortunately there probably are very few of these users.\n\n> The current warning message in jc/pull-training-wheel is quite neutral\n> between the two options. Perhaps we should lean more towards merging?\n\nI don't like that message. I would like this for the deprecation period:\n\n\"The pull was not fast-forward, in the future you would have to choose\na merge or a rebase, merging automatically for now. Read 'man git\npull' for more help.\"\n\nThen when obsolete:\n\nThe pull was not fast-forward, please either merge or rebase.\n\n\"Any more babysitting with essay long messages is counter-productive\nto the vast majority of Git users.\"\n\n> I guess that works against John's case, though, which is clueless people\n> working on a project that _does_ care about the shape of history. At\n> least they would have to stop and think for a moment, though, which\n> might help (and maybe convince them to ask more clueful project\n> members). I don't know.\n\nOr google 'git pull' 'git merge' 'git rebase' or 'git non-fast-forward'.\n\n-- \nFelipe Contreras\n"},{"id":"227077","messageId":"522C168B.7050300@bbn.com","threadId":"34821","inReplyTo":"CAMP44s0kMbXvcJbWvJDu=8A5iOeH4fsMGUdT-ehXKNXiV1FQ1Q@mail.gmail.com","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"Richard Hansen","fromEmail":"rhansen@bbn.com","sentAt":"2013-09-08T06:17:47Z","receivedAt":"2013-09-08T06:17:47Z","isPatch":true,"sender":{"key":"rhansen@rhansen.org","avatar":null},"body":"On 2013-09-07 22:41, Felipe Contreras wrote:\n> On Wed, Sep 4, 2013 at 5:59 PM, Junio C Hamano wrote:\n> \n>> Which can be solved by adding the above \"fail\" option, and then\n>> renaming them to \"pull.integrate\" and \"branch..integrate\" to\n>> clarify what these variables are about (it is no longer \"do you\n>> rebase or not---if you choose not to rebase, by definition you are\n>> going to merge\", as there is a third choice to \"fail\"), while\n>> retaining \"pull.rebase\" and \"branch..rebase\" as a deprecated\n>> synonym.\n> \n> All these names are completely unintuitive. First of all, why\n> \"integrate\"? Integrate what to what? And then, why \"fail\"? Fail on\n> what circumstances? Always?\n> \n> My proposal that does:\n> \n> pull.mode = merge/rebase/merge-ff-only\n> \n> Is way more intuitive.\n\n+1\n\nWhat about something like:\n\n pull.mergeoptions (defaults to --ff-only)\n pull.rebaseoptions (defaults to empty? --preserve-merges?)\n branch..pull.mergeoptions (defaults to pull.mergeoptions)\n branch..pull.rebaseoptions (defaults to pull.rebaseoptions)\n\n-Richard\n"},{"id":"227081","messageId":"20130908065420.GI14019@sigill.intra.peff.net","threadId":"34821","inReplyTo":"CAMP44s3U2rJsqTj4cAOpY1ntum53bEy2cP5XRNaMu5vwnYVoww@mail.gmail.com","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-09-08T06:54:20Z","receivedAt":"2013-09-08T06:54:20Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Sep 08, 2013 at 01:17:42AM -0500, Felipe Contreras wrote:\n\n> > I think it's fine to tell them to do \"git pull --merge\". What I'd worry\n> > more about is somebody who is suddenly presented with the choice between\n> > \"--rebase\" and \"--merge\" and doesn't know which to choose. We've created a\n> > cognitive load on the user, and even more load if they choose --rebase\n> > and don't quite understand what it means.\n> \n> If that happens they will go back to the guy that told them to run\n> those commands.\n\nI think \"the guy\" may be git itself. For example, here is a possible\nsession with jc/pull-training-wheel:\n\n $ git push\n To ...\n ! [rejected] master -> master (non-fast-forward)\n error: failed to push some refs to '...'\n hint: Updates were rejected because the tip of your current branch is behind\n hint: its remote counterpart. Integrate the remote changes (e.g.\n hint: 'git pull ...') before pushing again.\n hint: See the 'Note about fast-forwards' in 'git push --help' for details.\n\n $ git pull\n The pull does not fast-forward; please specify\n if you want to merge or rebase.\n\n Use either\n\n git pull --rebase\n git pull --merge\n\n You can also use 'git config pull.rebase true' (if you want --rebase) or\n 'git config pull.rebase false' (if you want --merge) to set this once for\n this project and forget about it.\n\nThe user is pointed at \"pull\" from \"push\", and then gets presented with\nthe \"merge or rebase\" choice. It may be that the advice you can find by\ngoogling \"merge vs rebase\" is enough to then help the person along\n(and/or we may need to improve the manpages in that respect).\n\nI am genuinely curious what people in favor of this feature would want\nto say in the documentation to a user encountering this choice for the\nfirst time. In my experience, rebasing introduces more complications,\nspecifically:\n\n 1. the merge is \"backwards\" with respect to ours/theirs\n\n 2. you may end up with difficult conflict resolution due to repeated\n changes over the same section of code. E.g., you write some buggy\n code and then fix it, but upstream has changed the same area.\n Rebasing involves first resolving your buggy version with the\n upstream code, and then resolving the fix on top of the previous\n resolution.\n\n 3. rewriting of commits found in other branches, which then need\n rebased on top of the branch you just rebased\n\n 4. a previously bug-free commit can show a bug after the rebase if\n other parts of the project changed (whereas with a merge, the bug\n would be attributable to the merge)\n\nI know those are all balanced by some advantages of rebasing, but I also\nthink they are things that can be troublesome for a user who does not\nfully grok the rebase process. I'm just wondering if we should mention\nboth, but steer people towards merging as the safer alternative (you\nmight have ugly history, but you are less likely to create a mess with\nduplicate commits or badly-resolved conflicts).\n\n> Fortunately there probably are very few of these users.\n\nMaybe. I am not sure how one would measure.\n\nIf you are interested, I can ask the opinion of some of the GitHub\ntrainers. They see a lot of new users and have a sense of what kinds of\nconfusion come up most frequently, what kinds of workflows they tend to\nsee, etc. Their experience may be biased towards corporate-ish users,\nthough, because those are the people who pay for training.\n\n> > The current warning message in jc/pull-training-wheel is quite neutral\n> > between the two options. Perhaps we should lean more towards merging?\n> \n> I don't like that message. I would like this for the deprecation period:\n> \n> \"The pull was not fast-forward, in the future you would have to choose\n> a merge or a rebase, merging automatically for now. Read 'man git\n> pull' for more help.\"\n> \n> Then when obsolete:\n> \n> The pull was not fast-forward, please either merge or rebase.\n\nA deprecation message helps people who are making the transition from an\nolder behavior to a newer one. It cannot help new users who start with a\ngit version after the deprecation period.\n\n> \"Any more babysitting with essay long messages is counter-productive\n> to the vast majority of Git users.\"\n\nI think that is what we have advice.* for.\n\n-Peff\n"},{"id":"227083","messageId":"CAMP44s3LLHL=oP2PFr4b7VD0dL4yGBOL00O_GWj8eZLrYNM3kg@mail.gmail.com","threadId":"34821","inReplyTo":"20130908065420.GI14019@sigill.intra.peff.net","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-09-08T07:15:17Z","receivedAt":"2013-09-08T07:15:17Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sun, Sep 8, 2013 at 1:54 AM, Jeff King wrote:\n> On Sun, Sep 08, 2013 at 01:17:42AM -0500, Felipe Contreras wrote:\n>\n>> > I think it's fine to tell them to do \"git pull --merge\". What I'd worry\n>> > more about is somebody who is suddenly presented with the choice between\n>> > \"--rebase\" and \"--merge\" and doesn't know which to choose. We've created a\n>> > cognitive load on the user, and even more load if they choose --rebase\n>> > and don't quite understand what it means.\n>>\n>> If that happens they will go back to the guy that told them to run\n>> those commands.\n>\n> I think \"the guy\" may be git itself. For example, here is a possible\n> session with jc/pull-training-wheel:\n>\n> $ git push\n\nWho told him to use 'git push'? Certainly not git.\n\n> To ...\n> ! [rejected] master -> master (non-fast-forward)\n> error: failed to push some refs to '...'\n> hint: Updates were rejected because the tip of your current branch is behind\n> hint: its remote counterpart. Integrate the remote changes (e.g.\n> hint: 'git pull ...') before pushing again.\n> hint: See the 'Note about fast-forwards' in 'git push --help' for details.\n>\n> $ git pull\n\n> The pull does not fast-forward; please specify\n> if you want to merge or rebase.\n>\n> Use either\n>\n> git pull --rebase\n> git pull --merge\n>\n> You can also use 'git config pull.rebase true' (if you want --rebase) or\n> 'git config pull.rebase false' (if you want --merge) to set this once for\n> this project and forget about it.\n\nWhy stop there? Post the whole man page already.\n\nMoreover, it's overly verbose on all the wrong and irrelevant\ninformation. If you are going to waste precious screen state, explain\nwth a \"non fast-forward\" is; people can figure out what a merge is,\nand maybe a rebase, but a \"non fast-forward\" definitely not.\n\n> The user is pointed at \"pull\" from \"push\", and then gets presented with\n> the \"merge or rebase\" choice. It may be that the advice you can find by\n> googling \"merge vs rebase\" is enough to then help the person along\n> (and/or we may need to improve the manpages in that respect).\n\nYes, but that's not the use-case we are talking about. You mentioned\nspecifically a \"svn-like\" worfklow where the guy was told by somebody\nelse to replace the svn commands with git ones.\n\nIf we are talking about a guy that is learning git, that's and\nentirely different case.\n\n> I am genuinely curious what people in favor of this feature would want\n> to say in the documentation to a user encountering this choice for the\n> first time. In my experience, rebasing introduces more complications,\n> specifically:\n\nYes, but it's what the user might want.\n\n> I know those are all balanced by some advantages of rebasing, but I also\n> think they are things that can be troublesome for a user who does not\n> fully grok the rebase process. I'm just wondering if we should mention\n> both, but steer people towards merging as the safer alternative (you\n> might have ugly history, but you are less likely to create a mess with\n> duplicate commits or badly-resolved conflicts).\n\nThe purpose of this change in the code is not to change the user\nbehavior. The choice of merge vs. rebase is entirely up to the user,\nand we are not changing that.\n\nThe purpose of this change is to avoid doing a merge when the user\nwanted a rebase, or maybe something more complicated. So a rebase\nbeing complicated is not an issue, because we know that's what the\nuser wants, that's the whole reason we are trying to avoid the\nautomated merge.\n\n>> Fortunately there probably are very few of these users.\n>\n> Maybe. I am not sure how one would measure.\n>\n> If you are interested, I can ask the opinion of some of the GitHub\n> trainers. They see a lot of new users and have a sense of what kinds of\n> confusion come up most frequently, what kinds of workflows they tend to\n> see, etc. Their experience may be biased towards corporate-ish users,\n> though, because those are the people who pay for training.\n\nAsk. I'm sure they will tell you doing merges by mistake with 'git\npull' is an issue.\n\n>> > The current warning message in jc/pull-training-wheel is quite neutral\n>> > between the two options. Perhaps we should lean more towards merging?\n>>\n>> I don't like that message. I would like this for the deprecation period:\n>>\n>> \"The pull was not fast-forward, in the future you would have to choose\n>> a merge or a rebase, merging automatically for now. Read 'man git\n>> pull' for more help.\"\n>>\n>> Then when obsolete:\n>>\n>> The pull was not fast-forward, please either merge or rebase.\n>\n> A deprecation message helps people who are making the transition from an\n> older behavior to a newer one. It cannot help new users who start with a\n> git version after the deprecation period.\n\nThe new users are told to either merge or rebase, if they don't know\nwhat that means, they will go on look it up, just like they looked up\nthe 'git pull' command in the first place.\n\n>> \"Any more babysitting with essay long messages is counter-productive\n>> to the vast majority of Git users.\"\n>\n> I think that is what we have advice.* for.\n\nI don't understand what that means.\n\n-- \nFelipe Contreras\n"},{"id":"227101","messageId":"20130908075046.GL14019@sigill.intra.peff.net","threadId":"34821","inReplyTo":"CAMP44s3LLHL=oP2PFr4b7VD0dL4yGBOL00O_GWj8eZLrYNM3kg@mail.gmail.com","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-09-08T07:50:46Z","receivedAt":"2013-09-08T07:50:46Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Sep 08, 2013 at 02:15:17AM -0500, Felipe Contreras wrote:\n\n> > I think \"the guy\" may be git itself. For example, here is a possible\n> > session with jc/pull-training-wheel:\n> >\n> > $ git push\n> \n> Who told him to use 'git push'? Certainly not git.\n\nAny of the hundreds of existing tutorials that teach basic git commands\nlike \"push\"?\n\n> > To ...\n> > ! [rejected] master -> master (non-fast-forward)\n> > error: failed to push some refs to '...'\n> > hint: Updates were rejected because the tip of your current branch is behind\n> > hint: its remote counterpart. Integrate the remote changes (e.g.\n> > hint: 'git pull ...') before pushing again.\n> > hint: See the 'Note about fast-forwards' in 'git push --help' for details.\n> [...]\n> \n> Why stop there? Post the whole man page already.\n> \n> Moreover, it's overly verbose on all the wrong and irrelevant\n> information. If you are going to waste precious screen state, explain\n> wth a \"non fast-forward\" is; people can figure out what a merge is,\n> and maybe a rebase, but a \"non fast-forward\" definitely not.\n\nNote that I was not trying to defend any of the messages, but only\nshowing a plausible mechanism by which a user with basic knowledge that\nhe wants to push may arrive at the question \"what is the difference\nbetween merge and rebase?\".\n\nIf you want to suggest revisions for the push message, go ahead. The\npush advice _is_ an attempt to define non-fast-forwards in plain\nlanguage without taking up too much space, but perhaps you can do\nbetter. You could even suggest omitting it entirely, but I'm not sure if\nthat is a good idea. It was not added in a vacuum; we lacked that advice\nfor many years, and people complained about it quite a bit until it was\nadded.\n\n> > The user is pointed at \"pull\" from \"push\", and then gets presented with\n> > the \"merge or rebase\" choice. It may be that the advice you can find by\n> > googling \"merge vs rebase\" is enough to then help the person along\n> > (and/or we may need to improve the manpages in that respect).\n> \n> Yes, but that's not the use-case we are talking about. You mentioned\n> specifically a \"svn-like\" worfklow where the guy was told by somebody\n> else to replace the svn commands with git ones.\n\nNo, I mentioned an \"svn-like\" workflow. I didn't say anything about how\nthey were told. They might have been told by a co-worker, or read a\nbrief tutorial on git, or read something like \"Git-SVN Crash Course\".\n\n> If we are talking about a guy that is learning git, that's and\n> entirely different case.\n\nThat is certainly what I meant to be talking about.\n\n> The purpose of this change in the code is not to change the user\n> behavior. The choice of merge vs. rebase is entirely up to the user,\n> and we are not changing that.\n\nRight, but by not doing anything by default, you are forcing the user to\nmake a decision. Right now, we strongly encourage merging by making it\nthe default, and you have to learn about rebasing separately. But a\nmessage that mentions them both as equals is going to lead to extra work\nfor the user; they have to figure out which one is most appropriate. My\nconcern is that this is non-trivial for new users, and that they may end\nup arbitrarily picking rebase, which is probably not doing them any\nfavors if they do not understand it.\n\nFor clueful users, choosing between the two is not hard. But some people\nseem to have trouble understanding the DAG. I don't know how large a\ngroup that is, and how any pain caused by this change might compare to\nthe times it will help.\n\n> > If you are interested, I can ask the opinion of some of the GitHub\n> > trainers. They see a lot of new users and have a sense of what kinds of\n> > confusion come up most frequently, what kinds of workflows they tend to\n> > see, etc. Their experience may be biased towards corporate-ish users,\n> > though, because those are the people who pay for training.\n> \n> Ask. I'm sure they will tell you doing merges by mistake with 'git\n> pull' is an issue.\n\nI've sent an email. I'll post the response when I get it.\n\n> >> \"Any more babysitting with essay long messages is counter-productive\n> >> to the vast majority of Git users.\"\n> >\n> > I think that is what we have advice.* for.\n> \n> I don't understand what that means.\n\nIt means that some time ago, after many people complained that git did\nnot give enough hints, we added many hints. Some people who did not need\nthese hints would want to disable them, and we have the \"advice.*\"\nconfig options to do so. So we can have a longer message for new users,\nand a shorter one for people who do not want to be bothered with the\nlong advice.\n\n-Peff\n"},{"id":"227102","messageId":"8B7F235220624B259BB32B293BCB3E96@PhilipOakley","threadId":"34821","inReplyTo":"CAMP44s1Rb2WKGD-QfNh055099R+9FHv9W8TA8Gfjp=qZh_7p7Q@mail.gmail.com","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-09-08T08:01:14Z","receivedAt":"2013-09-08T08:01:14Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Felipe Contreras\" \nSent: Sunday, September 08, 2013 3:34 AM\n> On Thu, Sep 5, 2013 at 3:06 AM, John Keeping \n> wrote:\n>> On Wed, Sep 04, 2013 at 03:59:18PM -0700, Junio C Hamano wrote:\n>>> Are there cases where you do not want to either rebase nor merge?\n>>> If so what do you want to do after \"git pull\" fetches from the other\n>>> side? Nothing?\n>>\n>> One other thing that I can see being useful occasionally is:\n>>\n>> git rebase @{u}@{1} --onto @{u}\n>>\n>> which allows local commits to be replayed onto a rewritten upstream\n>> branch.\n>>\n>> Although I agree with your side note below that people doing this may \n>> be\n>> better off fetching and then updating their local branch, \n>> particularly\n>> if @{1} is not the correct reflog entry for the upstream when they\n>> created the branch.\n>\n> That's why after recognizing the fact the you can't find the branch\n> point of a branch in Git, I decided to write patches to support the\n> @{tail} shorthand, which is basically the point where the branch was\n> created, or rebased to:\n>\n> https://github.com/felipec/git/commits/fc/base\n>\n> And if 'git rebase' was fixed to ignore the commits already in the\n> rebased onto branch, almost always what you would want to do is 'git\n> rebase @{tail} --onto @{upstream}'.\n>\nThe use case that trips me up (i.e. doesn't fit the above) is when I \nhave a branch that may need rebasing on (onto) pu, or may need rebasing \non master, or next, depending on what others have been doing.\n\nAs a Distributed VCS (i.e. others doing work independently), a rebase \nalways has the possibility that the world has moved on and one has to \nadapt to the new world order by moving location (--onto somewhere new), \nnot just fixing up the house (patch conflicts). When the update order is \nunknown there is no guaranteed solution (IIUC).\n\nYou are right that mostly what one wants to do is stick with ones \ncurrent location and patch up conflicts, it's just that one din't want \nany conflicts in the first place (i.e. the fast forward check). \n"},{"id":"227105","messageId":"CAMP44s2pw2TZSZ6pL-kx_QQCkjKrprERyvddCT-HTeo7uRNENA@mail.gmail.com","threadId":"34821","inReplyTo":"8B7F235220624B259BB32B293BCB3E96@PhilipOakley","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-09-08T08:16:06Z","receivedAt":"2013-09-08T08:16:06Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sun, Sep 8, 2013 at 3:01 AM, Philip Oakley wrote:\n> From: \"Felipe Contreras\" \n> Sent: Sunday, September 08, 2013 3:34 AM\n>\n>> On Thu, Sep 5, 2013 at 3:06 AM, John Keeping wrote:\n>>>\n>>> On Wed, Sep 04, 2013 at 03:59:18PM -0700, Junio C Hamano wrote:\n>>>>\n>>>> Are there cases where you do not want to either rebase nor merge?\n>>>> If so what do you want to do after \"git pull\" fetches from the other\n>>>> side? Nothing?\n>>>\n>>>\n>>> One other thing that I can see being useful occasionally is:\n>>>\n>>> git rebase @{u}@{1} --onto @{u}\n>>>\n>>> which allows local commits to be replayed onto a rewritten upstream\n>>> branch.\n>>>\n>>> Although I agree with your side note below that people doing this may be\n>>> better off fetching and then updating their local branch, particularly\n>>> if @{1} is not the correct reflog entry for the upstream when they\n>>> created the branch.\n>>\n>>\n>> That's why after recognizing the fact the you can't find the branch\n>> point of a branch in Git, I decided to write patches to support the\n>> @{tail} shorthand, which is basically the point where the branch was\n>> created, or rebased to:\n>>\n>> https://github.com/felipec/git/commits/fc/base\n>>\n>> And if 'git rebase' was fixed to ignore the commits already in the\n>> rebased onto branch, almost always what you would want to do is 'git\n>> rebase @{tail} --onto @{upstream}'.\n>>\n> The use case that trips me up (i.e. doesn't fit the above) is when I have a\n> branch that may need rebasing on (onto) pu, or may need rebasing on master,\n> or next, depending on what others have been doing.\n\nYes, so you would do:\n\n% git rebase --onto pu\n\nWhich would be translated to:\n\n% git rebase @{tail} --onto pu\n\nWhat's the problem?\n\n> As a Distributed VCS (i.e. others doing work independently), a rebase always\n> has the possibility that the world has moved on and one has to adapt to the\n> new world order by moving location (--onto somewhere new), not just fixing\n> up the house (patch conflicts). When the update order is unknown there is no\n> guaranteed solution (IIUC).\n\nYeah, but almost always you want to rebase onto @{upstream}.\n\n-- \nFelipe Contreras\n"},{"id":"227112","messageId":"01BEC88E9B724BA4986F2678A4D9F4E6@PhilipOakley","threadId":"34821","inReplyTo":"CAMP44s2pw2TZSZ6pL-kx_QQCkjKrprERyvddCT-HTeo7uRNENA@mail.gmail.com","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-09-08T08:42:03Z","receivedAt":"2013-09-08T08:42:03Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Felipe Contreras\" \nTo: \"Philip Oakley\" \nCc: \"John Keeping\" ; \"Junio C Hamano\" \n; ; \"Andreas Krey\" \n\nSent: Sunday, September 08, 2013 9:16 AM\nSubject: Re: [PATCH 0/3] Reject non-ff pulls by default\n\n\n> On Sun, Sep 8, 2013 at 3:01 AM, Philip Oakley \n> wrote:\n>> From: \"Felipe Contreras\" \n>> Sent: Sunday, September 08, 2013 3:34 AM\n>>\n>>> On Thu, Sep 5, 2013 at 3:06 AM, John Keeping \n>>> wrote:\n>>>>\n>>>> On Wed, Sep 04, 2013 at 03:59:18PM -0700, Junio C Hamano wrote:\n>>>>>\n>>>>> Are there cases where you do not want to either rebase nor merge?\n>>>>> If so what do you want to do after \"git pull\" fetches from the \n>>>>> other\n>>>>> side? Nothing?\n>>>>\n>>>>\n>>>> One other thing that I can see being useful occasionally is:\n>>>>\n>>>> git rebase @{u}@{1} --onto @{u}\n>>>>\n>>>> which allows local commits to be replayed onto a rewritten upstream\n>>>> branch.\n>>>>\n>>>> Although I agree with your side note below that people doing this \n>>>> may be\n>>>> better off fetching and then updating their local branch, \n>>>> particularly\n>>>> if @{1} is not the correct reflog entry for the upstream when they\n>>>> created the branch.\n>>>\n>>>\n>>> That's why after recognizing the fact the you can't find the branch\n>>> point of a branch in Git, I decided to write patches to support the\n>>> @{tail} shorthand, which is basically the point where the branch was\n>>> created, or rebased to:\n>>>\n>>> https://github.com/felipec/git/commits/fc/base\n>>>\n>>> And if 'git rebase' was fixed to ignore the commits already in the\n>>> rebased onto branch, almost always what you would want to do is 'git\n>>> rebase @{tail} --onto @{upstream}'.\n>>>\n>> The use case that trips me up (i.e. doesn't fit the above) is when I \n>> have a\n>> branch that may need rebasing on (onto) pu, or may need rebasing on \n>> master,\n>> or next, depending on what others have been doing.\n>\n> Yes, so you would do:\n>\n> % git rebase --onto pu\n>\n> Which would be translated to:\n>\n> % git rebase @{tail} --onto pu\n>\n> What's the problem?\n>\nThe 'problem' is (would be) that I don't yet know that I would need \nthe --onto pu until I discover (how?) that the default rebase would \nresult in conflicts.\n\n>> As a Distributed VCS (i.e. others doing work independently), a rebase \n>> always\n>> has the possibility that the world has moved on and one has to adapt \n>> to the\n>> new world order by moving location (--onto somewhere new), not just \n>> fixing\n>> up the house (patch conflicts). When the update order is unknown \n>> there is no\n>> guaranteed solution (IIUC).\n>\n> Yeah, but almost always you want to rebase onto @{upstream}.\n\nYeah, but almost always you want to \"check\" first *before* starting. \nThat is, 'git rebase --abort' should not be required from the (user's \nselected /git's) default invocation.\n\n--\nPhilip Oakley \n"},{"id":"227113","messageId":"CAMP44s3SbaMy7c_5W72J-hMx+xq+4VB5dV7ttCK=TVSbbYcr8A@mail.gmail.com","threadId":"34821","inReplyTo":"20130908075046.GL14019@sigill.intra.peff.net","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-09-08T08:43:56Z","receivedAt":"2013-09-08T08:43:56Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sun, Sep 8, 2013 at 2:50 AM, Jeff King wrote:\n> On Sun, Sep 08, 2013 at 02:15:17AM -0500, Felipe Contreras wrote:\n>\n>> > I think \"the guy\" may be git itself. For example, here is a possible\n>> > session with jc/pull-training-wheel:\n>> >\n>> > $ git push\n>>\n>> Who told him to use 'git push'? Certainly not git.\n>\n> Any of the hundreds of existing tutorials that teach basic git commands\n> like \"push\"?\n\nYou can't use a tutorial out there that just tells you to replace svn\ncommands with git alternatives, go to work and mess up the repository\nhistory.\n\nI'm trying to take the point of view of your hypothetical user working\non a repository where history is not important, but it seems more and\nmore than this person is just not real. If it's OK to push crappy\nmerges, somebody must have told him that was OK and provided him with\nthe commands.\n\nIf it's just some random person that read some random tutorial from\n'svn' -> 'git' working on a random repository that happens to accept\nmerges all over the place. Well I think that's a very very exceptional\nsituation.\n\nAnd this person still wouldn't have a problem finding another tutorial\nexplaining what a merge is.\n\n>> > To ...\n>> > ! [rejected] master -> master (non-fast-forward)\n>> > error: failed to push some refs to '...'\n>> > hint: Updates were rejected because the tip of your current branch is behind\n>> > hint: its remote counterpart. Integrate the remote changes (e.g.\n>> > hint: 'git pull ...') before pushing again.\n>> > hint: See the 'Note about fast-forwards' in 'git push --help' for details.\n>> [...]\n>>\n>> Why stop there? Post the whole man page already.\n>>\n>> Moreover, it's overly verbose on all the wrong and irrelevant\n>> information. If you are going to waste precious screen state, explain\n>> wth a \"non fast-forward\" is; people can figure out what a merge is,\n>> and maybe a rebase, but a \"non fast-forward\" definitely not.\n>\n> Note that I was not trying to defend any of the messages, but only\n> showing a plausible mechanism by which a user with basic knowledge that\n> he wants to push may arrive at the question \"what is the difference\n> between merge and rebase?\".\n\nYes, and this person would have to read it online, like everything\nelse, because clearly Git documentation would do a bad job at it.\nThat's why the online documentation was needed in the first place.\n\nThe first hits of 'git merge vs rebase' are rather useful:\nhttp://mislav.uniqpath.com/2013/02/merge-vs-rebase/\nhttp://stackoverflow.com/questions/16336014/git-merge-vs-rebase\nhttp://www.derekgourlay.com/archives/428\nhttp://blog.sourcetreeapp.com/2012/08/21/merge-or-rebase/\nhttp://git-scm.com/book/en/Git-Branching-Rebasing\n\nNotice how none of the results point to official documentation,\nprecisely because it's not really useful.\n\n> If you want to suggest revisions for the push message, go ahead. The\n> push advice _is_ an attempt to define non-fast-forwards in plain\n> language without taking up too much space, but perhaps you can do\n> better.\n\nI definitely can, but you would disagree.\n\nBut anyway, you are relying on the user having pushed first, what if\nhe is pulling first, or what if he doesn't have write access and is\nonly pulling?\n\n> You could even suggest omitting it entirely, but I'm not sure if\n> that is a good idea. It was not added in a vacuum; we lacked that advice\n> for many years, and people complained about it quite a bit until it was\n> added.\n\nI would have to see the evidence, as I have never seen any complaints\nabout that. The complains are about the UI, and they still remain.\n\n>> > The user is pointed at \"pull\" from \"push\", and then gets presented with\n>> > the \"merge or rebase\" choice. It may be that the advice you can find by\n>> > googling \"merge vs rebase\" is enough to then help the person along\n>> > (and/or we may need to improve the manpages in that respect).\n>>\n>> Yes, but that's not the use-case we are talking about. You mentioned\n>> specifically a \"svn-like\" worfklow where the guy was told by somebody\n>> else to replace the svn commands with git ones.\n>\n> No, I mentioned an \"svn-like\" workflow. I didn't say anything about how\n> they were told. They might have been told by a co-worker, or read a\n> brief tutorial on git, or read something like \"Git-SVN Crash Course\".\n\nOnce again, this doesn't make any sense. People can't just push crap\nmerges to any repository.\n\n>> If we are talking about a guy that is learning git, that's and\n>> entirely different case.\n>\n> That is certainly what I meant to be talking about.\n\nIf he is learning Git, then he will be looking for the meaning of a\nmerge and a rebase. The fact that the repository accepts crappy merges\nwouldn't be relevant.\n\n>> The purpose of this change in the code is not to change the user\n>> behavior. The choice of merge vs. rebase is entirely up to the user,\n>> and we are not changing that.\n>\n> Right, but by not doing anything by default, you are forcing the user to\n> make a decision.\n\nNo, it would be a warning first, he wouldn't be *forced* to make a\ndecision, only after the deprecation period is over.\n\nThen yes, if by then he hasn't learned that what he wants is a merge,\nhe would be forced to learn it.\n\n> Right now, we strongly encourage merging by making it\n> the default, and you have to learn about rebasing separately. But a\n> message that mentions them both as equals is going to lead to extra work\n> for the user; they have to figure out which one is most appropriate.\n\nNo, they don't need to figure out which is most appropriate, they only\nneed to figure out they have been doing merges all along.\n\nMy warning message achieves precisely that:\n\n\"The pull was not fast-forward, in the future you would have to choose\na merge or a rebase, merging automatically for now. For more\ninformation read 'git\npull --help'.\"\n\nThe part \"merging automatically for now\". This teaches the user that\n'git pull' is doing a merge, so by the time 'git pull' errors out, he\nknows he wants a merge, all he needs to figure out is how to do it,\nand 'git pull --help' would tell him that. Perhaps adding a \"(git pull\n--merge)\" to the deprecation warning would help, but I still don't see\nthe need in the final error.\n\nOnce again, nobody is forcing anybody to change their workflows.\n\n> My\n> concern is that this is non-trivial for new users, and that they may end\n> up arbitrarily picking rebase, which is probably not doing them any\n> favors if they do not understand it.\n\nWhy would they pick a rebase? If git tells them 'git pull' is doing a\nmerge for months, why would they choose to do something different?\n\n> For clueful users, choosing between the two is not hard. But some people\n> seem to have trouble understanding the DAG. I don't know how large a\n> group that is, and how any pain caused by this change might compare to\n> the times it will help.\n\nThey don't need to learn what's more appropriate, they can keep doing\nwhat they have been doing.\n\n>> > If you are interested, I can ask the opinion of some of the GitHub\n>> > trainers. They see a lot of new users and have a sense of what kinds of\n>> > confusion come up most frequently, what kinds of workflows they tend to\n>> > see, etc. Their experience may be biased towards corporate-ish users,\n>> > though, because those are the people who pay for training.\n>>\n>> Ask. I'm sure they will tell you doing merges by mistake with 'git\n>> pull' is an issue.\n>\n> I've sent an email. I'll post the response when I get it.\n>\n>> >> \"Any more babysitting with essay long messages is counter-productive\n>> >> to the vast majority of Git users.\"\n>> >\n>> > I think that is what we have advice.* for.\n>>\n>> I don't understand what that means.\n>\n> It means that some time ago, after many people complained that git did\n> not give enough hints, we added many hints. Some people who did not need\n> these hints would want to disable them, and we have the \"advice.*\"\n> config options to do so. So we can have a longer message for new users,\n> and a shorter one for people who do not want to be bothered with the\n> long advice.\n\nI don't see Junio's proposal being affected by this advice thing.\n\nAnd I have used and contributed to Git for many years, used it since\nday one, and this is the first time I hear about it. I doubt even a\ntiny fraction of Git users know about it. Where is the documentation\nabout that?\n\n-- \nFelipe Contreras\n"},{"id":"227114","messageId":"CAMP44s1ZjtVdj1wys_7VkBrmvGAkh9cfOpZ_22aVONMH3GdcRg@mail.gmail.com","threadId":"34821","inReplyTo":"01BEC88E9B724BA4986F2678A4D9F4E6@PhilipOakley","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-09-08T08:49:32Z","receivedAt":"2013-09-08T08:49:32Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sun, Sep 8, 2013 at 3:42 AM, Philip Oakley wrote:\n\n> The 'problem' is (would be) that I don't yet know that I would need the\n> --onto pu until I discover (how?) that the default rebase would result in\n> conflicts.\n\nI don't see what that has to do with an invocation of 'git rebase'\nwithout arguments, and @{tail}. There's absolutely no way Git can\nfigure out for you which is the appropriate place for you to rebase\nonto.\n\nHowever, it shouldn't be too difficult to write a tool that checks\nmultiple commits and tells you on top of which ones a rebase could\nwork, but I don't think 'git rebase' is the right place.\n\n-- \nFelipe Contreras\n"},{"id":"227119","messageId":"5E98A1684FFB4A7D93A17A609F92A1B3@PhilipOakley","threadId":"34821","inReplyTo":"CAMP44s1ZjtVdj1wys_7VkBrmvGAkh9cfOpZ_22aVONMH3GdcRg@mail.gmail.com","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-09-08T10:02:59Z","receivedAt":"2013-09-08T10:02:59Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Felipe Contreras\" \nSent: Sunday, September 08, 2013 9:49 AM\n> On Sun, Sep 8, 2013 at 3:42 AM, Philip Oakley \n> wrote:\n>\n>> The 'problem' is (would be) that I don't yet know that I would need \n>> the\n>> --onto pu until I discover (how?) that the default rebase would \n>> result in\n>> conflicts.\n>\n> I don't see what that has to do with an invocation of 'git rebase'\n> without arguments, and @{tail}.\n\n> There's absolutely no way Git can\n> figure out for you which is the appropriate place for you to rebase\n> onto.\n.. which was my point. I may not have explained it that well.\n\nGiven that Git can't figure it out, we should stop trying in such cases.\n\n>\n> However, it shouldn't be too difficult to write a tool that checks\n> multiple commits and tells you on top of which ones a rebase could\n> work, but I don't think 'git rebase' is the right place.\n\nThat's an SOS approach (Success Oriented Script)[1] that presumes the \nuser is already better than they are - The Kruger Dunning paper [2] \noffers some insight into capability misconceptions (at all levels).\n\n--\nregards\n\nPhilip\n--\n[1] in the original it was a \"Success Oriented Schedule\" - one of those \nplans that hopeful managers put together on late running projects that \namount to wishful thinking that hopefully garners them enough time to \nmake a little progress and update their 'success stories'.\n[2] http://dx.doi.org/10.1111%2F1467-8721.01235 \"Why People Fail to \nRecognize Their Own Incompetence\". Though the corollaries (People fail \nto recognise their own skills, and hence they/we mishandle our \ncommunications) are just as (IMHO more) important. \n"},{"id":"227120","messageId":"20130908100351.GI2582@serenity.lan","threadId":"34821","inReplyTo":"20130908065420.GI14019@sigill.intra.peff.net","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2013-09-08T10:03:52Z","receivedAt":"2013-09-08T10:03:52Z","isPatch":true,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Sun, Sep 08, 2013 at 02:54:20AM -0400, Jeff King wrote:\n> I am genuinely curious what people in favor of this feature would want\n> to say in the documentation to a user encountering this choice for the\n> first time. In my experience, rebasing introduces more complications,\n> specifically:\n> \n> 1. the merge is \"backwards\" with respect to ours/theirs\n> \n> 2. you may end up with difficult conflict resolution due to repeated\n> changes over the same section of code. E.g., you write some buggy\n> code and then fix it, but upstream has changed the same area.\n> Rebasing involves first resolving your buggy version with the\n> upstream code, and then resolving the fix on top of the previous\n> resolution.\n> \n> 3. rewriting of commits found in other branches, which then need\n> rebased on top of the branch you just rebased\n> \n> 4. a previously bug-free commit can show a bug after the rebase if\n> other parts of the project changed (whereas with a merge, the bug\n> would be attributable to the merge)\n> \n> I know those are all balanced by some advantages of rebasing, but I also\n> think they are things that can be troublesome for a user who does not\n> fully grok the rebase process. I'm just wondering if we should mention\n> both, but steer people towards merging as the safer alternative (you\n> might have ugly history, but you are less likely to create a mess with\n> duplicate commits or badly-resolved conflicts).\n\nThe really correct thing to do here is to encourage a feature branch\nworkflow, but in my experience people are happier to walk through a\nrebase than to switch over to feature branches completely.\n\nAn alternative pull mode would be:\n\n git reset --keep @{u} &&\n git merge @{-1}\n\nwhich gets a sensible history shape without any of your disadvantages\nabove. But that didn't go anywhere last time it came up [1] [2].\n\n[1] http://article.gmane.org/gmane.comp.version-control.git/210246\n[2] http://article.gmane.org/gmane.comp.version-control.git/210625\n\n> > Fortunately there probably are very few of these users.\n> \n> Maybe. I am not sure how one would measure.\n> \n> If you are interested, I can ask the opinion of some of the GitHub\n> trainers. They see a lot of new users and have a sense of what kinds of\n> confusion come up most frequently, what kinds of workflows they tend to\n> see, etc. Their experience may be biased towards corporate-ish users,\n> though, because those are the people who pay for training.\n\nI expect corporate environments are the ones in which this is relevant.\nOpen source projects that care about the shape of history can have one\nperson able to write to the central repository who can enforce the\npolicy they want. This tends to be more difficult in a corporate\nenvironment, particularly one that was previously using a centralised\nVCS.\n"},{"id":"227122","messageId":"96F33621753B40E2AB55648FAEAB3445@PhilipOakley","threadId":"34821","inReplyTo":"5E98A1684FFB4A7D93A17A609F92A1B3@PhilipOakley","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-09-08T10:39:14Z","receivedAt":"2013-09-08T10:39:14Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Philip Oakley\" \n> [2] http://dx.doi.org/10.1111%2F1467-8721.01235 \"Why People Fail to \n> Recognize Their Own Incompetence\".\n\nOops, That's behind a paywall, and a more recent variant.\n\n> Though the corollaries \n> (People fail to recognise their own skills, and hence they/we \n> mishandle our communications) are just as (IMHO more) important.\n\nI believe this is the on-line version of the original 1999 paper\nhttp://mastercodeprofessional.com/library_files/Kruger-Dunning---Unskilled_and_Unaware_of_It_(2009).pdf\n\nThe section 5.1. \"The Burden of Expertise\" discusses my point above.\n\"they [Experts] fail to realize that their proficiency is not \nnecessarily shared by their peers.\"\n\nPhilip\n"},{"id":"227142","messageId":"20130908172605.GF5359@vauxhall.crustytoothpaste.net","threadId":"34821","inReplyTo":"CAMP44s01LL2JCKzqa0Qc5MfBz9zfMXR4H8jZdauLOi-D0JVHpw@mail.gmail.com","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2013-09-08T17:26:06Z","receivedAt":"2013-09-08T17:26:06Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On Sat, Sep 07, 2013 at 11:37:13PM -0500, Felipe Contreras wrote:\n> On Sat, Sep 7, 2013 at 11:18 PM, Jeff King wrote:\n> > By \"svn-like\", I mean the people whose workflow is:\n> >\n> > $ hack hack hack\n> > $ git commit\n> > $ git push ;# oops, somebody else pushed in the meantime\n> > $ git pull\n> > $ git push\n\nIt's possible that some teams at work may be using this workflow. It's\nmore likely that there would be a rebase if the push failed, but some\nteams might do a merge. I don't know because we don't dictate workflow\nto individual teams for the reasons I get into below. Regardless,\nmerges are our typical workflow, so forcing rebase mode all the time\nwouldn't be appropriate for us.\n\n> > $ hack hack hack\n> > $ svn commit ;# oops, somebody else committed in the meantime\n> > $ svn update\n> > $ svn commit\n> >\n> > Those people would now have to learn enough to choose between merge and\n> > rebase when running the \"git pull\".\n> \n> But that's only if they don't care about the shape of history. In my\n> experience the people that cling more to centralized VCS do not like\n> merges, so they rebase everything to make it a straight line. That is\n> much more \"svn-like\".\n> \n> So chances are they are already doing 'git pull --rebase' (or\n> similar), so their workflow wouldn't be affected.\n\nWe end up squashing each project branch into one commit (usually using\ngit reset --soft), so we don't care about the shape of history. Over\nthe course of a project branch, in fact, there may be many merges from\nthe main release branches (including other projects), so history is\ngoing to be very messy otherwise.\n\n-- \nbrian m. carlson / brian with sandals: Houston, Texas, US\n+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only\nOpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187\n"},{"id":"227144","messageId":"xmqqa9jn6v6q.fsf@gitster.dls.corp.google.com","threadId":"34821","inReplyTo":"522C168B.7050300@bbn.com","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-09-08T18:10:37Z","receivedAt":"2013-09-08T18:10:37Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Richard Hansen writes:\n\n> On 2013-09-07 22:41, Felipe Contreras wrote:\n>> On Wed, Sep 4, 2013 at 5:59 PM, Junio C Hamano wrote:\n>> \n>>> Which can be solved by adding the above \"fail\" option, and then\n>>> renaming them to \"pull.integrate\" and \"branch..integrate\" to\n>>> clarify what these variables are about (it is no longer \"do you\n>>> rebase or not---if you choose not to rebase, by definition you are\n>>> going to merge\", as there is a third choice to \"fail\"), while\n>>> retaining \"pull.rebase\" and \"branch..rebase\" as a deprecated\n>>> synonym.\n>> \n>> All these names are completely unintuitive. First of all, why\n>> \"integrate\"? Integrate what to what? And then, why \"fail\"? Fail on\n>> what circumstances? Always?\n>> \n>> My proposal that does:\n>> \n>> pull.mode = merge/rebase/merge-ff-only\n>> \n>> Is way more intuitive.\n>\n> +1\n>\n> What about something like:\n>\n> pull.mergeoptions (defaults to --ff-only)\n> pull.rebaseoptions (defaults to empty? --preserve-merges?)\n> branch..pull.mergeoptions (defaults to pull.mergeoptions)\n> branch..pull.rebaseoptions (defaults to pull.rebaseoptions)\n\nAs \"pull\" has two distinct phases \"fetch\" and \"merge/rebase\", your\nmergeoptions/rebaseoptions is much better than \"mode\", which does\nnot tell which phase of \"pull\" the mode refers to. It is clear that\nthey apply to the process to integrate the history obtained from\nthe other side and your own history into one history.\n\nBut it does not help Philip's case, if I understand correctly, where\nrunning \"git pull\" on some branches is always a mistake and the user\nwants it to stop at \"fetch the history and objects needed to\ncomplete the history from the other side\" phase without proceeding\nto the \"then integrate the history from the other side and the\nhistory of your branch into one\" step, which may be done with either\nmerge or rebase. Even if we ignore that \"always fail, do not do\nanything\" use case, your two seemingly independent \"mergeoptions\"\nand \"rebaseoptions\" do not tell us which one is preferred between\nmerge and rebase. A single\n\n pull. = rebase | merge [| always-fail]\n\nmakes that choice in a clear way, I think.\n\nRegarding the verb \"integrate\".\n\nWe used to explain \"pull\" is a \"fetch\" followed by a \"merge\". With\nmore people using \"git pull --rebase\", the word \"merge\" used in that\nexplanation of \"pull\" stopped being generic enough. Simplarily the\n\"upstream branch\" of local branch X is \"what you fetch and merge to\nupdate the branch X\" but that 'merge' can be 'rebase'. We needed a\nverb to call the process of integrate the two histories into one.\n\n\"git pull --help\" since 153d7265 (pull: change the description to\n\"integrate\" changes, 2013-07-07) uses that verb [*1*].\n\nAnd that is where the name of the single configuration to pick how\nto integrate the history obtained by the first phase of \"pull\" came\nfrom.\n\n\n[Footnote]\n\n*1* I suspect that there may still be places in the documentation\nthat have not been updated since the days back when the only valid\nway to integrate two lines of histories was to merge, and updating\nthem may be a low-hanging fruit. Hint, hint.\n \n"},{"id":"227147","messageId":"522CD88A.3060708@bbn.com","threadId":"34821","inReplyTo":"xmqqa9jn6v6q.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"Richard Hansen","fromEmail":"rhansen@bbn.com","sentAt":"2013-09-08T20:05:30Z","receivedAt":"2013-09-08T20:05:30Z","isPatch":true,"sender":{"key":"rhansen@rhansen.org","avatar":null},"body":"On 2013-09-08 14:10, Junio C Hamano wrote:\n> Richard Hansen writes:\n>> What about something like:\n>>\n>> pull.mergeoptions (defaults to --ff-only)\n>> pull.rebaseoptions (defaults to empty? --preserve-merges?)\n>> branch..pull.mergeoptions (defaults to pull.mergeoptions)\n>> branch..pull.rebaseoptions (defaults to pull.rebaseoptions)\n> \n[snip]\n> But it does not help Philip's case, if I understand correctly, where\n> running \"git pull\" on some branches is always a mistake and the user\n> wants it to stop at \"fetch the history and objects needed to\n> complete the history from the other side\" phase without proceeding\n> to the \"then integrate the history from the other side and the\n> history of your branch into one\" step, which may be done with either\n> merge or rebase.\n\nHow about:\n\n branch..pull.defaultIntegrationMode = merge | rebase | none\n If 'merge', pull acts like 'git pull --merge' by default,\n merging the other commits into this branch.\n If 'rebase', pull acts like 'git pull --rebase' by default,\n rebasing this branch onto the other commits.\n If 'none', pull acts like 'git fetch' by default.\n Default: whatever pull.defaultIntegrationMode is set to.\n\n branch..pull.mergeoptions\n Arguments to pass to 'git merge' during the merge phase of\n 'git pull --merge'.\n Default: whatever pull.mergeoptions is set to.\n\n branch..pull.rebaseoptions\n Arguments to pass to 'git rebase' during the rebase phase of\n 'git pull --rebase'.\n Default: whatever pull.rebaseoptions is set to.\n\n pull.defaultIntegrationMode = rebase | merge | none\n See branch..pull.defaultIntegrationMode.\n Default: merge\n\n pull.mergeoptions\n See branch..pull.mergeoptions.\n Default: empty, but warn that a future version will change\n this to --ff-only.\n\n pull.rebaseoptions\n See branch..pull.rebaseoptions.\n Default: empty, but warn that a future version will change\n this to --preserve-merges?\n\nThere's probably a better alternative to the term 'defaultIntegrationMode'.\n\nWe could even add a defaultIntegrationMode = merge-there that\nreverses the parent order (the other commits become the first parent,\nthe current branch becomes the second parent).\n\n-Richard\n"},{"id":"227159","messageId":"CAMP44s0SLoD7ptgiYOg_vq+Jpo5uhWvzFC8Bd76JHo5zbjf8fg@mail.gmail.com","threadId":"34821","inReplyTo":"20130908172605.GF5359@vauxhall.crustytoothpaste.net","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-09-08T22:38:50Z","receivedAt":"2013-09-08T22:38:50Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sun, Sep 8, 2013 at 12:26 PM, brian m. carlson\n wrote:\n> On Sat, Sep 07, 2013 at 11:37:13PM -0500, Felipe Contreras wrote:\n>> On Sat, Sep 7, 2013 at 11:18 PM, Jeff King wrote:\n\n>> > $ hack hack hack\n>> > $ svn commit ;# oops, somebody else committed in the meantime\n>> > $ svn update\n>> > $ svn commit\n>> >\n>> > Those people would now have to learn enough to choose between merge and\n>> > rebase when running the \"git pull\".\n>>\n>> But that's only if they don't care about the shape of history. In my\n>> experience the people that cling more to centralized VCS do not like\n>> merges, so they rebase everything to make it a straight line. That is\n>> much more \"svn-like\".\n>>\n>> So chances are they are already doing 'git pull --rebase' (or\n>> similar), so their workflow wouldn't be affected.\n>\n> We end up squashing each project branch into one commit (usually using\n> git reset --soft), so we don't care about the shape of history. Over\n> the course of a project branch, in fact, there may be many merges from\n> the main release branches (including other projects), so history is\n> going to be very messy otherwise.\n\nYeah, but the key question at hand in this discussion is; what happens\nwhen 'git pull' stops working for them, and they don't know what to\ndo, will they choose 'git pull --rebase' by mistake?\n\nI say the answer is no, because:\n\n1) As you say in your scenario, somebody is telling these guys what to\ndo, so when 'git pull' fails, somebody will figure out that they were\ndoing a merge, so 'git pull --merge' is what they want to type from\nnow on.\n\n2) Git itself would be warning them for months that a 'non\nfast-forward was found, and a merge will be done for them', so when\nthe warning turns to an error, they'll know they want a merge, so\nthey'll do 'git pull --merge', either because the warning told them\nthat's git was doing all along, or because they figured that out by\ngoogling, or reading the man page, or whatever.\n\nEither way, it would not be a big deal for these people, their\nuser-experience wouldn't be totally broken by this proposed change,\nand that is the important conclusion.\n\n-- \nFelipe Contreras\n"},{"id":"227160","messageId":"62FDB1B489D749349DDEE076E689C32E@PhilipOakley","threadId":"34821","inReplyTo":"xmqqa9jn6v6q.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-09-08T22:46:18Z","receivedAt":"2013-09-08T22:46:18Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Junio C Hamano\" \nSent: Sunday, September 08, 2013 7:10 PM\n> Richard Hansen writes:\n>\n>> On 2013-09-07 22:41, Felipe Contreras wrote:\n>>> On Wed, Sep 4, 2013 at 5:59 PM, Junio C Hamano \n>>> wrote:\n>>>\n>>>> Which can be solved by adding the above \"fail\" option, and then\n>>>> renaming them to \"pull.integrate\" and \"branch..integrate\" to\n>>>> clarify what these variables are about (it is no longer \"do you\n>>>> rebase or not---if you choose not to rebase, by definition you are\n>>>> going to merge\", as there is a third choice to \"fail\"), while\n>>>> retaining \"pull.rebase\" and \"branch..rebase\" as a deprecated\n>>>> synonym.\n>>>\n>>> All these names are completely unintuitive. First of all, why\n>>> \"integrate\"? Integrate what to what? And then, why \"fail\"? Fail on\n>>> what circumstances? Always?\n>>>\n>>> My proposal that does:\n>>>\n>>> pull.mode = merge/rebase/merge-ff-only\n>>>\n>>> Is way more intuitive.\n>>\n>> +1\n>>\n>> What about something like:\n>>\n>> pull.mergeoptions (defaults to --ff-only)\n>> pull.rebaseoptions (defaults to empty? --preserve-merges?)\n>> branch..pull.mergeoptions (defaults to pull.mergeoptions)\n>> branch..pull.rebaseoptions (defaults to pull.rebaseoptions)\n>\n> As \"pull\" has two distinct phases \"fetch\" and \"merge/rebase\", your\n> mergeoptions/rebaseoptions is much better than \"mode\", which does\n> not tell which phase of \"pull\" the mode refers to. It is clear that\n> they apply to the process to integrate the history obtained from\n> the other side and your own history into one history.\n>\n> But it does not help Philip's case, if I understand correctly, where\n> running \"git pull\" on some branches is always a mistake\n\nNot quite always, it's when it won't fast forward\n\n> and the user\n> wants it to stop at \"fetch the history and objects needed to\n> complete the history from the other side\" phase without proceeding\n> to the \"then integrate the history from the other side and the\n> history of your branch into one\" step,\n\nYes, it/Git should stop and wait for instructions...\n\n> which may be done with either\n> merge or rebase.\n\nHere I would typically rebase onto an adjusted destination, e.g. onto \npu, or maybe next, rather than master (or vice versa depending on \nexpectations). That is its a feature branch that needs to decide what \nit's on top of (well, I need to decide ;-)\n\n> Even if we ignore that \"always fail, do not do\n> anything\" use case, your two seemingly independent \"mergeoptions\"\n> and \"rebaseoptions\" do not tell us which one is preferred between\n> merge and rebase. A single\n>\n> pull. = rebase | merge [| always-fail]\n>\n> makes that choice in a clear way, I think.\n\nor 'fail on non-ff' (which may or may not be the users, or Git's \ndefault, as per the series title ;-)\n\n>\n> Regarding the verb \"integrate\".\n>\n> We used to explain \"pull\" is a \"fetch\" followed by a \"merge\". With\n> more people using \"git pull --rebase\", the word \"merge\" used in that\n> explanation of \"pull\" stopped being generic enough. Simplarily the\n> \"upstream branch\" of local branch X is \"what you fetch and merge to\n> update the branch X\" but that 'merge' can be 'rebase'. We needed a\n> verb to call the process of integrate the two histories into one.\n>\n> \"git pull --help\" since 153d7265 (pull: change the description to\n> \"integrate\" changes, 2013-07-07) uses that verb [*1*].\n>\n> And that is where the name of the single configuration to pick how\n> to integrate the history obtained by the first phase of \"pull\" came\n> from.\n>\n>\n> [Footnote]\n>\n> *1* I suspect that there may still be places in the documentation\n> that have not been updated since the days back when the only valid\n> way to integrate two lines of histories was to merge, and updating\n> them may be a low-hanging fruit. Hint, hint.\n>\n>\n--\nPhilip\n"},{"id":"227161","messageId":"CAMP44s01wK3Cf1ChOx=J7YKv0VgjYQB+NvyTt4-Mahsu4qG4iw@mail.gmail.com","threadId":"34821","inReplyTo":"xmqqa9jn6v6q.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-09-08T22:46:59Z","receivedAt":"2013-09-08T22:46:59Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sun, Sep 8, 2013 at 1:10 PM, Junio C Hamano wrote:\n\n> pull. = rebase | merge [| always-fail]\n>\n> makes that choice in a clear way, I think.\n>\n> Regarding the verb \"integrate\".\n\nI doubt anybody thinks of pull being an \"integration\", and even if it\nis, it's still doesn't explain what 'integration = merge' means. To be\nhuman friendly you would need to say 'integration-type' or\n'integration-kind', or 'integration-mode', then a human would\nunderstand, \"oh yeah, the mode I'm using to integrated is a merge, got\nya'.\n\nBut why bother with yet another useless concept the user has to learn?\nThe user doesn't need to learn about this concept of \"integration\",\nall the user wants is to map:\n\ngit pull --rebase\n=> pull. = rebase\n\ngit pull --merge\npull. = merge\n\nThat's it. And my proposed name, 'mode' does the trick just fine.\n\npull.mode = rebase | merge | merge-no-ff\n\n-- \nFelipe Contreras\n"},{"id":"227167","messageId":"CALkWK0m3ZQLkHU4sJntkeJ1Lrogjd_-Z8Q2KzpAPP28Ghf6SMQ@mail.gmail.com","threadId":"34821","inReplyTo":"CAMP44s01wK3Cf1ChOx=J7YKv0VgjYQB+NvyTt4-Mahsu4qG4iw@mail.gmail.com","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-09-08T23:11:24Z","receivedAt":"2013-09-08T23:11:24Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Felipe Contreras wrote:\n> On Sun, Sep 8, 2013 at 1:10 PM, Junio C Hamano wrote:\n>\n>> pull. = rebase | merge [| always-fail]\n>>\n>> makes that choice in a clear way, I think.\n\nThe core issue is that users rarely want to merge locally: that's the\nmaintainer's job. Users simply want to rebase, and develop on\ndifferent branches that they will rebase onto origin. I like Felipe's\nidea for using a pull.mode.\n"},{"id":"227173","messageId":"20130909000153.GG5359@vauxhall.crustytoothpaste.net","threadId":"34821","inReplyTo":"CAMP44s0SLoD7ptgiYOg_vq+Jpo5uhWvzFC8Bd76JHo5zbjf8fg@mail.gmail.com","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2013-09-09T00:01:54Z","receivedAt":"2013-09-09T00:01:54Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On Sun, Sep 08, 2013 at 05:38:50PM -0500, Felipe Contreras wrote:\n> Yeah, but the key question at hand in this discussion is; what happens\n> when 'git pull' stops working for them, and they don't know what to\n> do, will they choose 'git pull --rebase' by mistake?\n\nI agree, they will not choose git pull --rebase by mistake.\n\n> I say the answer is no, because:\n> \n> 1) As you say in your scenario, somebody is telling these guys what to\n> do, so when 'git pull' fails, somebody will figure out that they were\n> doing a merge, so 'git pull --merge' is what they want to type from\n> now on.\n\nYes, that would be me. My hesitance here is that as the one usually\ndriving git updates (which so far have happened once a year), I will end\nup retraining forty developers. I don't think the current behavior is\nbroken or really problematic at all: merging has always been the\ndefault, and people have come to expect that. People using workflows\nthat don't want merge have always either needed to set a configuration\noption or use --rebase. As the man page says, --rebase is unsafe, and\nthat's why it's not the default.\n\nI would be much less unhappy with your earlier change that did not\naffect uses with arguments. That would limit the number of use cases\naffected.\n\n> 2) Git itself would be warning them for months that a 'non\n> fast-forward was found, and a merge will be done for them', so when\n> the warning turns to an error, they'll know they want a merge, so\n> they'll do 'git pull --merge', either because the warning told them\n> that's git was doing all along, or because they figured that out by\n> googling, or reading the man page, or whatever.\n\nAgain, you assume that git updates happen on a regular basis, and you\nassume that most developers really know what happens under the hood.\n\nI don't see a warning now; in fact, I see:\n\n vauxhall ok % git status\n # On branch master\n # Your branch and 'upstream/master' have diverged,\n # and have 1 and 128 different commits each, respectively.\n # (use \"git pull\" to merge the remote branch into yours)\n #\n\nThe current behavior of git is to explicitly encourage this behavior,\nand now you want to make it not work. I think this change is a bad\nidea, and I think the number of changes required to the test suite\nindicates that. If there's going to be a change here, it should have a\ndeprecation period with the above message changed and appropriate\nwarnings, not a flag day; your patches don't do that.\n\n-- \nbrian m. carlson / brian with sandals: Houston, Texas, US\n+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only\nOpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187\n"},{"id":"227176","messageId":"CAMP44s2seqO_0o=G2PjoL77HNSNcjTe4s6ZYj90_wsUT30pW8A@mail.gmail.com","threadId":"34821","inReplyTo":"20130909000153.GG5359@vauxhall.crustytoothpaste.net","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-09-09T00:29:35Z","receivedAt":"2013-09-09T00:29:35Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sun, Sep 8, 2013 at 7:01 PM, brian m. carlson\n wrote:\n> On Sun, Sep 08, 2013 at 05:38:50PM -0500, Felipe Contreras wrote:\n>> Yeah, but the key question at hand in this discussion is; what happens\n>> when 'git pull' stops working for them, and they don't know what to\n>> do, will they choose 'git pull --rebase' by mistake?\n>\n> I agree, they will not choose git pull --rebase by mistake.\n>\n>> I say the answer is no, because:\n>>\n>> 1) As you say in your scenario, somebody is telling these guys what to\n>> do, so when 'git pull' fails, somebody will figure out that they were\n>> doing a merge, so 'git pull --merge' is what they want to type from\n>> now on.\n>\n> Yes, that would be me. My hesitance here is that as the one usually\n> driving git updates (which so far have happened once a year), I will end\n> up retraining forty developers. I don't think the current behavior is\n> broken or really problematic at all: merging has always been the\n> default, and people have come to expect that.\n\nIt may not be broken for you, but it is for other people. Would you be\nso egocentric as to ignore everybody else because \"it works for you\"?\n\n> People using workflows\n> that don't want merge have always either needed to set a configuration\n> option or use --rebase. As the man page says, --rebase is unsafe, and\n> that's why it's not the default.\n\nYes, but the problem is that people using other workflows end up\navoiding 'git pull' at all, so at the end of the day we have one core\ncommand that the majority of users avoid, that's not good.\n\n> I would be much less unhappy with your earlier change that did not\n> affect uses with arguments. That would limit the number of use cases\n> affected.\n\nI have no problem with:\ngit pull $remote $branch\n\nAllowing non-fast-forward merges.\n\nAnd:\ngit pull $remote\ngit pull\n\nNot allowing them by default.\n\nBut the problem is that it's not easy to implement.\n\nEither way, I'll venture that you don't want 'git pull $remote' to\nchange, so it would be a waste of the time to try to get the above to\nwork.\n\n>> 2) Git itself would be warning them for months that a 'non\n>> fast-forward was found, and a merge will be done for them', so when\n>> the warning turns to an error, they'll know they want a merge, so\n>> they'll do 'git pull --merge', either because the warning told them\n>> that's git was doing all along, or because they figured that out by\n>> googling, or reading the man page, or whatever.\n>\n> Again, you assume that git updates happen on a regular basis, and you\n> assume that most developers really know what happens under the hood.\n\nNo. The developers don't have to know what happens under the hood, Git\nwould be telling them \"WARNING: we are doing a merge\", what else is\nthe developer to think, but that 'git pull' is doing a merge?\n\nAs for the updates, yes, I assume updates happen at least each three\nmonths. If your company updates each year, I don't see what much more\nwe can do to you help you. Doing a single change per year is certainly\ngoing to hold the project back.\n\nFortunately this was only point 2), there's still point 1); you can\ntell them to use 'git pull --merge' from now on, and since you update\nonce every year, you can do it while you give the training for the\nyear.\n\nOr there's another option:\n\n3) Distribute Git in your company with /etc/gitconfig having pull.mode\n= merge. This way nothing will change.\n\nI think we are being very accommodating to your company's use-case\nwhich is very far from the norm. Even in the absolute worst case\nscenario, you would have to tell people to use 'git pull --merge'\ninstead, is that really so horrible? Should we really halt Git's\nprogress because you would have to tell people to type nine extra\ncharacters or run one configuration command?\n\n> I don't see a warning now; in fact, I see:\n>\n> vauxhall ok % git status\n> # On branch master\n> # Your branch and 'upstream/master' have diverged,\n> # and have 1 and 128 different commits each, respectively.\n> # (use \"git pull\" to merge the remote branch into yours)\n> #\n>\n> The current behavior of git is to explicitly encourage this behavior,\n> and now you want to make it not work.\n\nYes, that's why it's a change.\n\n> I think this change is a bad\n> idea, and I think the number of changes required to the test suite\n> indicates that. If there's going to be a change here, it should have a\n> deprecation period with the above message changed and appropriate\n> warnings, not a flag day; your patches don't do that.\n\nMy patches pretty much do nothing else but introduce a warning.\nNothing is broken, nothing is changed in the test suite:\n\nhttp://article.gmane.org/gmane.comp.version-control.git/233669\n\nYou are confusing my proposal with Junio's one.\n\nAlso, my proposal was to enable this behavior (pull.mode =\nmerge-ff-only) only for Git v2.0, which might happen probably way\nlater than a year from now, so you your users might actually see the\nwarning after all. But yeah, that's _my_ proposal.\n\n-- \nFelipe Contreras\n"},{"id":"227177","messageId":"CAMP44s3WPUW3z-1Jthfr7R-xw1ufiub4vA8j9jXuk-cpO1hwVQ@mail.gmail.com","threadId":"34821","inReplyTo":"CAMP44s2seqO_0o=G2PjoL77HNSNcjTe4s6ZYj90_wsUT30pW8A@mail.gmail.com","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-09-09T00:36:21Z","receivedAt":"2013-09-09T00:36:21Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sun, Sep 8, 2013 at 7:29 PM, Felipe Contreras\n wrote:\n\n> My patches pretty much do nothing else but introduce a warning.\n> Nothing is broken, nothing is changed in the test suite:\n>\n> http://article.gmane.org/gmane.comp.version-control.git/233669\n>\n> You are confusing my proposal with Junio's one.\n\nActually my mistake. My patches don't even add a warning, so nothing\nis changed at all (unless you manually configure pull.mode =\nmerge-ff-only).\n\nI only suggested to add the warning, but didn't actually implement it.\nI'll do that soon.\n\n-- \nFelipe Contreras\n"},{"id":"227179","messageId":"20130909003855.GH5359@vauxhall.crustytoothpaste.net","threadId":"34821","inReplyTo":"CAMP44s3WPUW3z-1Jthfr7R-xw1ufiub4vA8j9jXuk-cpO1hwVQ@mail.gmail.com","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2013-09-09T00:38:55Z","receivedAt":"2013-09-09T00:38:55Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On Sun, Sep 08, 2013 at 07:36:21PM -0500, Felipe Contreras wrote:\n> On Sun, Sep 8, 2013 at 7:29 PM, Felipe Contreras\n> wrote:\n> \n> > My patches pretty much do nothing else but introduce a warning.\n> > Nothing is broken, nothing is changed in the test suite:\n> >\n> > http://article.gmane.org/gmane.comp.version-control.git/233669\n> >\n> > You are confusing my proposal with Junio's one.\n> \n> Actually my mistake. My patches don't even add a warning, so nothing\n> is changed at all (unless you manually configure pull.mode =\n> merge-ff-only).\n> \n> I only suggested to add the warning, but didn't actually implement it.\n> I'll do that soon.\n\nI still wouldn't be crazy about the change, but if there's a warning, I\ncould live with it. I think that's probably the best course of action\nif there's going to be a change here.\n\n-- \nbrian m. carlson / brian with sandals: Houston, Texas, US\n+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only\nOpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187\n"},{"id":"227203","messageId":"vpqr4cy4g5q.fsf@anie.imag.fr","threadId":"34821","inReplyTo":"CAMP44s2seqO_0o=G2PjoL77HNSNcjTe4s6ZYj90_wsUT30pW8A@mail.gmail.com","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-09-09T07:18:09Z","receivedAt":"2013-09-09T07:18:09Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Felipe Contreras writes:\n\n> On Sun, Sep 8, 2013 at 7:01 PM, brian m. carlson\n> wrote:\n>\n>> Yes, that would be me. My hesitance here is that as the one usually\n>> driving git updates (which so far have happened once a year), I will end\n>> up retraining forty developers. I don't think the current behavior is\n>> broken or really problematic at all: merging has always been the\n>> default, and people have come to expect that.\n>\n> It may not be broken for you, but it is for other people. Would you be\n> so egocentric as to ignore everybody else because \"it works for you\"?\n\nIt's not a matter of \"works for me\". Git currently \"works\" for all use\ncases because you can already merge or rebase. The proposed changes are\nnot about allowing the behavior that works, but disallowing the behavior\nthat doesn't.\n\nI agree that allowing people to reject non-ff merge is a good idea.\n\nI strongly disagree that this should eventually become the default,\nthough. I think it should really remain an opt-in (possibly with some\nnon-scary warning advertizing for the feature).\n\nFirst, the discussions on this thread show that it's hard to find the\nright behavior. My guess is that it's hard because we're trying to think\nfor the users. I've used GNU Arch for a while, and this VCS was trying\nto impose what the developer thought was good for me. I had to fight\nwith the tool whenever I tried to do something \"non-standard\". I don't\nwant to go back there. Preventing _users_ to do something because _we_\nconsidered it was bad for them is wrong IMHO.\n\nI already mentionned another reason in\nhttp://thread.gmane.org/gmane.comp.version-control.git/225146/focus=229162 :\n\"git rebase\" is hard to use for many people. With \"git merge\", doing\nthings wrong isn't so bad. If you forget to commit after a conflicted\nmerge, you'll mix your changes with the merge, this is bad, but it\nworks. With \"git rebase\", if you forget to \"git rebase --continue\" after\na conflict, you end up in detached HEAD, with part of your own changes\ndiscarded. If my students end up in this situation, they'll stop using\nGit and exchange files by email.\n\n\"git pull\" is one of the first things one learns with Git, and\n_requiring_ users to chose between merge and rebase is a nonsense at\nthis time of learning.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"227243","messageId":"xmqq1u4x4yst.fsf@gitster.dls.corp.google.com","threadId":"34821","inReplyTo":"vpqr4cy4g5q.fsf@anie.imag.fr","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-09-09T18:47:45Z","receivedAt":"2013-09-09T18:47:45Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\n> First, the discussions on this thread show that it's hard to find the\n> right behavior. My guess is that it's hard because we're trying to think\n> for the users. I've used GNU Arch for a while, and this VCS was trying\n> to impose what the developer thought was good for me. I had to fight\n> with the tool whenever I tried to do something \"non-standard\". I don't\n> want to go back there.\n\nFond memories of tla comes back to me as well ... ;-)\n\n> Preventing _users_ to do something because _we_ considered it was\n> bad for them is wrong IMHO.\n> I already mentionned another reason in\n> http://thread.gmane.org/gmane.comp.version-control.git/225146/focus=229162 :\n> \"git rebase\" is hard to use for many people.\n> ...\n> \"git pull\" is one of the first things one learns with Git, and\n> _requiring_ users to chose between merge and rebase is a nonsense at\n> this time of learning.\n\nAfter I re-read that message, I am starting to think that the topic\nthat has been cooking in 'next' that attempts to catch \"git pull\"\n(no \"from where, integrate with what\" parameters) may already be bad\nby that standard. Brian Carlson's comments on the impact on existing\nusers seems to the same direction to me.\n\nYou are in favor of an _option_ to allow people to forbid a pull in\na non-ff situation, and I think other people are also in\nagreement. So perhaps:\n\n - drop jc/pull-training-wheel and revert its merge from 'next';\n\n - update Felipe's series with a bit of tweak to make it less\n impactful by demoting error into warning and advice.\n\nwould be a good way forward?\n"},{"id":"227251","messageId":"20130909195231.GA14021@sigill.intra.peff.net","threadId":"34821","inReplyTo":"xmqq1u4x4yst.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-09-09T19:52:31Z","receivedAt":"2013-09-09T19:52:31Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Sep 09, 2013 at 11:47:45AM -0700, Junio C Hamano wrote:\n\n> You are in favor of an _option_ to allow people to forbid a pull in\n> a non-ff situation, and I think other people are also in\n> agreement. So perhaps:\n> \n> - drop jc/pull-training-wheel and revert its merge from 'next';\n> \n> - update Felipe's series with a bit of tweak to make it less\n> impactful by demoting error into warning and advice.\n> \n> would be a good way forward?\n\nI think that would address the concern I raised, because it does not\ncreate a roadblock to new users accomplishing their task. They can\nignore the warning, or choose \"merge\" as the default to shut up the\nwarning (and it is easy to choose that if you are confused, because it\nis what git is doing by default alongside the warning).\n\n-Peff\n"},{"id":"227254","messageId":"20130909200438.GD14021@sigill.intra.peff.net","threadId":"34821","inReplyTo":"20130908100351.GI2582@serenity.lan","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-09-09T20:04:39Z","receivedAt":"2013-09-09T20:04:39Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Sep 08, 2013 at 11:03:52AM +0100, John Keeping wrote:\n\n> > I know those are all balanced by some advantages of rebasing, but I also\n> > think they are things that can be troublesome for a user who does not\n> > fully grok the rebase process. I'm just wondering if we should mention\n> > both, but steer people towards merging as the safer alternative (you\n> > might have ugly history, but you are less likely to create a mess with\n> > duplicate commits or badly-resolved conflicts).\n> \n> The really correct thing to do here is to encourage a feature branch\n> workflow, but in my experience people are happier to walk through a\n> rebase than to switch over to feature branches completely.\n> \n> An alternative pull mode would be:\n> \n> git reset --keep @{u} &&\n> git merge @{-1}\n> \n> which gets a sensible history shape without any of your disadvantages\n> above. But that didn't go anywhere last time it came up [1] [2].\n\nFWIW, that approach makes some sense to me. De-coupling for a moment the\nidea of \"what is the default\" from \"what are the options\", it seems like\ndoing a reverse-merge would be a good option to have in the toolbox.\n\nIt would also have other uses beyond \"git pull\". For example, in\ndevelopment of GitHub itself, we use topic branches. But before merging\nthem to master, we often test-deploy the topic to the live site. Before\ndoing so, you have to merge the topic with the latest master to make\nsure you are not un-deploying anybody else's recently graduated topics.\n\nYou can do so by creating a temporary merge branch and deploying that,\nor you can simply merge master back into the topic. We generally choose\nthe latter, because it leaves any conflict resolution in an obvious\nplace (and doesn't need repeating).\n\n-Peff\n"},{"id":"227255","messageId":"20130909201751.GA14437@sigill.intra.peff.net","threadId":"34821","inReplyTo":"20130908075046.GL14019@sigill.intra.peff.net","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-09-09T20:17:51Z","receivedAt":"2013-09-09T20:17:51Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Sep 08, 2013 at 03:50:46AM -0400, Jeff King wrote:\n\n> > > If you are interested, I can ask the opinion of some of the GitHub\n> > > trainers. They see a lot of new users and have a sense of what kinds of\n> > > confusion come up most frequently, what kinds of workflows they tend to\n> > > see, etc. Their experience may be biased towards corporate-ish users,\n> > > though, because those are the people who pay for training.\n> > \n> > Ask. I'm sure they will tell you doing merges by mistake with 'git\n> > pull' is an issue.\n> \n> I've sent an email. I'll post the response when I get it.\n\nHere is what I sent them (I am leaving both my mail and theirs unedited\nto avoid any \"telephone\"-like confusion in trying to summarize):\n\n Right now, running \"git pull\" will always create a merge, unless\n the user has specifically configured it to perform a rebase.\n Some people find this problematic, because the project may care\n about the order of merges (e.g., so that --first-parent\n traversals do the right thing), and some users may accidentally\n do \"backwards\" merges from a main branch into a topic (either\n because they are clueless, or because they simply forgot).\n\n There is a proposal being considered to have \"git pull\" do\n nothing by default, but instead ask the user to specify whether\n to merge or rebase (with the option of setting a config value if\n you want it to do one by default).\n\n One concern I have is that new users may run across this\n relatively early. For example, the first time they \"git push\"\n and get a non-fast-forward because somebody else has already\n pushed, git suggests to run \"git pull\". At which point they will\n have to decide whether to merge or rebase. So what I'd like your\n opinions on is:\n\n 1. Do new users have trouble with the concept of rebase vs\n merge? How would they handle this change of behavior?\n\n 2. Do new users have trouble with rebases in general? There\n are some complications over doing a normal merge, but I\n don't know how often they trip people up in practice.\n\nAnd the responses I got were:\n\n 1. New users definitely have trouble distinguishing between\n rebase and merge. Even people who have been using Git for a\n while on a basic level are sometimes confused by this.\n\n 2. Most people we teach—even the ones who have been using Git\n for a while—don't know what a rebase is at all. They've heard of\n it, but they don't get it. It takes careful explanation to get\n the concept across and explain why it is not the same thing as a\n merge.\n\n Speaking for myself, about half of the time in the Foundations\n class I'll explain `pull --rebase` and `branch.autosetuprebase`.\n (Whether we get to it depends on class interest and ability.)\n When we do address that topic, we always recommend that\n rebase-on-pull is the right thing to do, since the merges Git\n creates are just noise that makes history hard to work with in\n the ways you have pointed out. (For smart classes, I like to\n make the analogy of Git to a distributed database, and point out\n how the merge on pull is just Git's mechanism for resolving\n split-brain writes. I explain that those merges aren't a\n deficiency in Git; they're just what has to happen by default.\n The fact that Git handles split-brain writes so well by itself\n is amazing.)\n\n My input would be to continue to have `pull` merge by default.\n Those merges aren't great, but new users won't have any idea how\n to make a decision about them at that point. As it is, it just\n works, and it works quite elegantly. Once you start to learn\n some things, you can tune Git up to work even more elegantly by\n rebasing, but having to understand that concept and make a\n decision on your first (or second or third or twentieth) pull is\n probably asking too much.\n\nand:\n\n Just a few more elements to add:\n\n * I have been teaching rebase and what it means in _some_ of my\n Git Foundations classes as of late. But \"some\" means there are\n a majority that do not get it.\n\n * These are the people that get \"formal\" training on Git. What\n about all the newbies? They really won't have a foundation for\n what these two \"flavors\" mean.\n\n * The merge is very different from what Subversion presents as a\n default. That's a possible point in the \"option's favor.\"\n\n * In the end though, the \"simplest thing that works\" should be\n the default without a choice. To me, a choice implies knowledge\n of the benefits of each option. I would say that the majority\n of our Git students do not, at the beginning of Git usage,\n understand the difference.\n\nI did not specifically ask in the original about whether backwards\nmerges were a problem, though I think that is touched on in the\nresponses.\n\nIf you'd like me to ask something specifically, I can relay the\nquestion, or I can ask them to come join the discussion here.\n\n-Peff\n"},{"id":"227256","messageId":"20130909202435.GJ2582@serenity.lan","threadId":"34821","inReplyTo":"20130909195231.GA14021@sigill.intra.peff.net","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2013-09-09T20:24:35Z","receivedAt":"2013-09-09T20:24:35Z","isPatch":true,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Mon, Sep 09, 2013 at 03:52:31PM -0400, Jeff King wrote:\n> On Mon, Sep 09, 2013 at 11:47:45AM -0700, Junio C Hamano wrote:\n> \n> > You are in favor of an _option_ to allow people to forbid a pull in\n> > a non-ff situation, and I think other people are also in\n> > agreement. So perhaps:\n> > \n> > - drop jc/pull-training-wheel and revert its merge from 'next';\n> > \n> > - update Felipe's series with a bit of tweak to make it less\n> > impactful by demoting error into warning and advice.\n> > \n> > would be a good way forward?\n> \n> I think that would address the concern I raised, because it does not\n> create a roadblock to new users accomplishing their task. They can\n> ignore the warning, or choose \"merge\" as the default to shut up the\n> warning (and it is easy to choose that if you are confused, because it\n> is what git is doing by default alongside the warning).\n\nI think we need to make sure that we give instructions for how to go\nback if the default hasn't done what you wanted. Something like this:\n\n Your pull did not fast-forward, so Git has merged '$upstream' into\n your branch, which may not be correct for your project. If you\n would rather rebase your changes, run\n\n git rebase\n\n See \"pull.mode\" in git-config(1) to suppress this message in the\n future.\n\n?\n"},{"id":"227257","messageId":"20130909204415.GC14536@sigill.intra.peff.net","threadId":"34821","inReplyTo":"20130909202435.GJ2582@serenity.lan","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-09-09T20:44:16Z","receivedAt":"2013-09-09T20:44:16Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Sep 09, 2013 at 09:24:35PM +0100, John Keeping wrote:\n\n> > I think that would address the concern I raised, because it does not\n> > create a roadblock to new users accomplishing their task. They can\n> > ignore the warning, or choose \"merge\" as the default to shut up the\n> > warning (and it is easy to choose that if you are confused, because it\n> > is what git is doing by default alongside the warning).\n> \n> I think we need to make sure that we give instructions for how to go\n> back if the default hasn't done what you wanted. Something like this:\n> \n> Your pull did not fast-forward, so Git has merged '$upstream' into\n> your branch, which may not be correct for your project. If you\n> would rather rebase your changes, run\n> \n> git rebase\n> \n> See \"pull.mode\" in git-config(1) to suppress this message in the\n> future.\n\nYes, that's a good point. I don't know if just \"git rebase\" is the right\nadvice, though; it would depend on whether we were actually pulling from\nthe upstream or not.\n\nI wonder if we have sufficient information at the time of the warning to\nprint out the actual \"git rebase\" invocation that would rebase as if\nthey had run \"pull --rebase\". I think we may have to do a little\nrefactoring around the base selection from the reflog (IIRC, git-pull\ndoes not even calculate it at all if you are not using --rebase).\n\nIt is also depending on \"git rebase\" throwing away the merge commit we\njust created. Which I think should happen always if you have not\nconfigured anything (though perhaps we will eventually support a pull\nmode that does \"rebase -p\", you would not see this warning with that\noption anyway). But another option would be to simply tell them:\n\n git reset --keep HEAD^\n git pull --rebase [X...]\n\nwhere \"[X...]\" is the arguments they gave to rebase in the first place.\nThat looks a little less friendly, though.\n\n-Peff\n"},{"id":"227258","messageId":"vpqbo41lo2v.fsf@anie.imag.fr","threadId":"34821","inReplyTo":"xmqq1u4x4yst.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-09-09T20:47:20Z","receivedAt":"2013-09-09T20:47:20Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano writes:\n\n> You are in favor of an _option_ to allow people to forbid a pull in\n> a non-ff situation, and I think other people are also in\n> agreement.\n\nYes. Having an option can't harm anybody, and there's a clear demand for\nthat.\n\n> So perhaps:\n>\n> - drop jc/pull-training-wheel and revert its merge from 'next';\n>\n> - update Felipe's series with a bit of tweak to make it less\n> impactful by demoting error into warning and advice.\n>\n> would be a good way forward?\n\nI didn't follow very closely the discussions and patch series, but that\nwould sound right to me. The last version of Felipes' patch series\nalready gives a warning only, but the wording and commit message implies\nthat this will become an error in the future (this is the part with\nwhich I disagree).\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"227260","messageId":"vpq38pdlnxk.fsf@anie.imag.fr","threadId":"34821","inReplyTo":"20130909202435.GJ2582@serenity.lan","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-09-09T20:50:31Z","receivedAt":"2013-09-09T20:50:31Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"John Keeping writes:\n\n> I think we need to make sure that we give instructions for how to go\n> back if the default hasn't done what you wanted. Something like this:\n>\n> Your pull did not fast-forward, so Git has merged '$upstream' into\n> your branch, which may not be correct for your project. If you\n> would rather rebase your changes, run\n>\n> git rebase\n>\n> See \"pull.mode\" in git-config(1) to suppress this message in the\n> future.\n\nSounds good to me. One option is to display the warning on the\ncommand-line, and another option is to show it in COMMIT_EDITMSG (since\nwe now default to showing it even for non-conflicted merges).\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"227261","messageId":"20130909205349.GA15506@sigill.intra.peff.net","threadId":"34821","inReplyTo":"vpq38pdlnxk.fsf@anie.imag.fr","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-09-09T20:53:49Z","receivedAt":"2013-09-09T20:53:49Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Sep 09, 2013 at 10:50:31PM +0200, Matthieu Moy wrote:\n\n> John Keeping writes:\n> \n> > I think we need to make sure that we give instructions for how to go\n> > back if the default hasn't done what you wanted. Something like this:\n> >\n> > Your pull did not fast-forward, so Git has merged '$upstream' into\n> > your branch, which may not be correct for your project. If you\n> > would rather rebase your changes, run\n> >\n> > git rebase\n> >\n> > See \"pull.mode\" in git-config(1) to suppress this message in the\n> > future.\n> \n> Sounds good to me. One option is to display the warning on the\n> command-line, and another option is to show it in COMMIT_EDITMSG (since\n> we now default to showing it even for non-conflicted merges).\n\nI hadn't though of that, but showing it in COMMIT_EDITMSG is a great\nmoment, because you are notifying the user _before_ they create a merge\ncommit. So the backout/switch procedure is \"cancel this by giving an\nempty message, then re-run git pull --rebase\".\n\nOn the other hand, if we run into conflicts, you'd probably want to let\nthem know before asking them to resolve them all. So perhaps a separate\nmessage would be needed for that case (to suggest \"reset --merge && git\npull --rebase\").\n\n-Peff\n"},{"id":"227262","messageId":"20130909211052.GK2582@serenity.lan","threadId":"34821","inReplyTo":"20130909204415.GC14536@sigill.intra.peff.net","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2013-09-09T21:10:52Z","receivedAt":"2013-09-09T21:10:52Z","isPatch":true,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Mon, Sep 09, 2013 at 04:44:16PM -0400, Jeff King wrote:\n> On Mon, Sep 09, 2013 at 09:24:35PM +0100, John Keeping wrote:\n> \n> > > I think that would address the concern I raised, because it does not\n> > > create a roadblock to new users accomplishing their task. They can\n> > > ignore the warning, or choose \"merge\" as the default to shut up the\n> > > warning (and it is easy to choose that if you are confused, because it\n> > > is what git is doing by default alongside the warning).\n> > \n> > I think we need to make sure that we give instructions for how to go\n> > back if the default hasn't done what you wanted. Something like this:\n> > \n> > Your pull did not fast-forward, so Git has merged '$upstream' into\n> > your branch, which may not be correct for your project. If you\n> > would rather rebase your changes, run\n> > \n> > git rebase\n> > \n> > See \"pull.mode\" in git-config(1) to suppress this message in the\n> > future.\n> \n> Yes, that's a good point. I don't know if just \"git rebase\" is the right\n> advice, though; it would depend on whether we were actually pulling from\n> the upstream or not.\n> \n> I wonder if we have sufficient information at the time of the warning to\n> print out the actual \"git rebase\" invocation that would rebase as if\n> they had run \"pull --rebase\". I think we may have to do a little\n> refactoring around the base selection from the reflog (IIRC, git-pull\n> does not even calculate it at all if you are not using --rebase).\n\nWe can probably do something like:\n\n opts=\n if git merge-base --is-ancestor \"$orig_head\" \"$merge_head\"\n then\n opts=$merge_head\n else\n opts=\"$orig_head --onto $merge_head\"\n fi\n\nso that \"git rebase $opts\" is the right thing. Most users then get the\nsimple \"git rebase $merge_head\" variant.\n\n> It is also depending on \"git rebase\" throwing away the merge commit we\n> just created. Which I think should happen always if you have not\n> configured anything (though perhaps we will eventually support a pull\n> mode that does \"rebase -p\", you would not see this warning with that\n> option anyway). But another option would be to simply tell them:\n> \n> git reset --keep HEAD^\n> git pull --rebase [X...]\n> \n> where \"[X...]\" is the arguments they gave to rebase in the first place.\n> That looks a little less friendly, though.\n\nYeah, I think we should keep it simple if possible. In my experience\npeople are relatively happy to run a single \"make things right\" command\nbut less so if there's a sequence of steps to be performed.\n"},{"id":"227267","messageId":"FE7D06F70ABF477DA271A6A596C1F1E9@PhilipOakley","threadId":"34821","inReplyTo":"20130909205349.GA15506@sigill.intra.peff.net","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-09-09T21:34:29Z","receivedAt":"2013-09-09T21:34:29Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Jeff King\" \nSent: Monday, September 09, 2013 9:53 PM\n> On Mon, Sep 09, 2013 at 10:50:31PM +0200, Matthieu Moy wrote:\n>\n>> John Keeping writes:\n>>\n>> > I think we need to make sure that we give instructions for how to \n>> > go\n>> > back if the default hasn't done what you wanted. Something like \n>> > this:\n>> >\n>> > Your pull did not fast-forward, so Git has merged '$upstream' \n>> > into\n>> > your branch, which may not be correct for your project. If you\n>> > would rather rebase your changes, run\n>> >\n>> > git rebase\n>> >\n>> > See \"pull.mode\" in git-config(1) to suppress this message in \n>> > the\n>> > future.\n>>\n>> Sounds good to me. One option is to display the warning on the\n>> command-line, and another option is to show it in COMMIT_EDITMSG \n>> (since\n>> we now default to showing it even for non-conflicted merges).\n>\n> I hadn't though of that, but showing it in COMMIT_EDITMSG is a great\n> moment, because you are notifying the user _before_ they create a \n> merge\n> commit. So the backout/switch procedure is \"cancel this by giving an\n> empty message, then re-run git pull --rebase\".\n>\n> On the other hand, if we run into conflicts, you'd probably want to \n> let\n> them know before asking them to resolve them all. So perhaps a \n> separate\n> message would be needed for that case (to suggest \"reset --merge && \n> git\n> pull --rebase\").\n\nIn fact this [running into conflicts unexpectedly] is usually my use \ncase, which I mis-described as a no-ff in an earlier reply.\n\nUsually I'd want a clean rebase before submitting patches, but I can see \nother uses cases where there is a desire that branches show where they \nstarted so rebase wouldn't be appropriate.\n\nIt should not be necessary to give prescriptions about how to backout of \na difficult corner, rather give details about how to go forward after \nstopping safely and early. The urge to press on (various proposals) may \nnot be the right thing.\n\nPhilip \n"},{"id":"227268","messageId":"522E4241.1040105@bbn.com","threadId":"34821","inReplyTo":"20130909204415.GC14536@sigill.intra.peff.net","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"Richard Hansen","fromEmail":"rhansen@bbn.com","sentAt":"2013-09-09T21:48:49Z","receivedAt":"2013-09-09T21:48:49Z","isPatch":true,"sender":{"key":"rhansen@rhansen.org","avatar":null},"body":"On 2013-09-09 16:44, Jeff King wrote:\n> On Mon, Sep 09, 2013 at 09:24:35PM +0100, John Keeping wrote:\n>> I think we need to make sure that we give instructions for how to go\n>> back if the default hasn't done what you wanted. Something like this:\n>>\n>> Your pull did not fast-forward, so Git has merged '$upstream' into\n>> your branch, which may not be correct for your project. If you\n>> would rather rebase your changes, run\n>>\n>> git rebase\n>>\n>> See \"pull.mode\" in git-config(1) to suppress this message in the\n>> future.\n> \n> Yes, that's a good point. I don't know if just \"git rebase\" is the right\n> advice, though; it would depend on whether we were actually pulling from\n> the upstream or not.\n\nAnother reason 'git rebase' might not be the right advice: We don't\nwant to encourage users to flatten intentional merges. For example:\n\n $ git checkout master\n $ git merge --no-ff just-finished-feature-branch\n $ git push\n ! [rejected] master -> master (non-fast-forward)\n $ git pull\n WARNING: Your pull did not fast-forward [...] run git rebase\n\nIf 'git rebase' is run here, the commits on just-finished-feature-branch\nwill be linearized onto @{u}, which is not what the user wants.\n\nPerhaps one could argue that a user that gets into this situation and is\nnormally comfortable running 'git rebase' is already experienced enough\nto know to ignore the advice to run 'git rebase'.\n\n(Sidenote: Unfortunately there's not an easy way to recover from this\ncase without adding another merge commit. But that's a topic for\nanother thread.)\n\n-Richard\n"},{"id":"227282","messageId":"CAMP44s0rypiQtmQPAHA6QHvAE6HmOMmYKi1sTpze+dmifLumFw@mail.gmail.com","threadId":"34821","inReplyTo":"20130909201751.GA14437@sigill.intra.peff.net","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-09-09T22:59:53Z","receivedAt":"2013-09-09T22:59:53Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Mon, Sep 9, 2013 at 3:17 PM, Jeff King wrote:\n> On Sun, Sep 08, 2013 at 03:50:46AM -0400, Jeff King wrote:\n>\n>> > > If you are interested, I can ask the opinion of some of the GitHub\n>> > > trainers. They see a lot of new users and have a sense of what kinds of\n>> > > confusion come up most frequently, what kinds of workflows they tend to\n>> > > see, etc. Their experience may be biased towards corporate-ish users,\n>> > > though, because those are the people who pay for training.\n>> >\n>> > Ask. I'm sure they will tell you doing merges by mistake with 'git\n>> > pull' is an issue.\n>>\n>> I've sent an email. I'll post the response when I get it.\n>\n> Here is what I sent them (I am leaving both my mail and theirs unedited\n> to avoid any \"telephone\"-like confusion in trying to summarize):\n>\n> Right now, running \"git pull\" will always create a merge, unless\n> the user has specifically configured it to perform a rebase.\n> Some people find this problematic, because the project may care\n> about the order of merges (e.g., so that --first-parent\n> traversals do the right thing), and some users may accidentally\n> do \"backwards\" merges from a main branch into a topic (either\n> because they are clueless, or because they simply forgot).\n>\n> There is a proposal being considered to have \"git pull\" do\n> nothing by default, but instead ask the user to specify whether\n> to merge or rebase (with the option of setting a config value if\n> you want it to do one by default).\n>\n> One concern I have is that new users may run across this\n> relatively early. For example, the first time they \"git push\"\n> and get a non-fast-forward because somebody else has already\n> pushed, git suggests to run \"git pull\". At which point they will\n> have to decide whether to merge or rebase. So what I'd like your\n> opinions on is:\n>\n> 1. Do new users have trouble with the concept of rebase vs\n> merge? How would they handle this change of behavior?\n>\n> 2. Do new users have trouble with rebases in general? There\n> are some complications over doing a normal merge, but I\n> don't know how often they trip people up in practice.\n>\n> And the responses I got were:\n>\n> 1. New users definitely have trouble distinguishing between\n> rebase and merge. Even people who have been using Git for a\n> while on a basic level are sometimes confused by this.\n>\n> 2. Most people we teach—even the ones who have been using Git\n> for a while—don't know what a rebase is at all. They've heard of\n> it, but they don't get it. It takes careful explanation to get\n> the concept across and explain why it is not the same thing as a\n> merge.\n>\n> Speaking for myself, about half of the time in the Foundations\n> class I'll explain `pull --rebase` and `branch.autosetuprebase`.\n> (Whether we get to it depends on class interest and ability.)\n> When we do address that topic, we always recommend that\n> rebase-on-pull is the right thing to do, since the merges Git\n> creates are just noise that makes history hard to work with in\n> the ways you have pointed out. (For smart classes, I like to\n> make the analogy of Git to a distributed database, and point out\n> how the merge on pull is just Git's mechanism for resolving\n> split-brain writes. I explain that those merges aren't a\n> deficiency in Git; they're just what has to happen by default.\n> The fact that Git handles split-brain writes so well by itself\n> is amazing.)\n>\n> My input would be to continue to have `pull` merge by default.\n> Those merges aren't great, but new users won't have any idea how\n> to make a decision about them at that point. As it is, it just\n> works, and it works quite elegantly. Once you start to learn\n> some things, you can tune Git up to work even more elegantly by\n> rebasing, but having to understand that concept and make a\n> decision on your first (or second or third or twentieth) pull is\n> probably asking too much.\n>\n> and:\n>\n> Just a few more elements to add:\n>\n> * I have been teaching rebase and what it means in _some_ of my\n> Git Foundations classes as of late. But \"some\" means there are\n> a majority that do not get it.\n>\n> * These are the people that get \"formal\" training on Git. What\n> about all the newbies? They really won't have a foundation for\n> what these two \"flavors\" mean.\n>\n> * The merge is very different from what Subversion presents as a\n> default. That's a possible point in the \"option's favor.\"\n>\n> * In the end though, the \"simplest thing that works\" should be\n> the default without a choice. To me, a choice implies knowledge\n> of the benefits of each option. I would say that the majority\n> of our Git students do not, at the beginning of Git usage,\n> understand the difference.\n\nWall these concerns can be tackled with an error message that says:\n\n\"The pull was not fast-forward, please either merge or rebase. If\nunsure, run 'git pull --merge'.\"\n\n-- \nFelipe Contreras\n"},{"id":"227283","messageId":"CAMP44s0y-cpEWuPTQSwC-Hyp-RNcwdyDRTbAsUewH5bAPPMXuQ@mail.gmail.com","threadId":"34821","inReplyTo":"20130909202435.GJ2582@serenity.lan","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-09-09T23:02:35Z","receivedAt":"2013-09-09T23:02:35Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Mon, Sep 9, 2013 at 3:24 PM, John Keeping wrote:\n> On Mon, Sep 09, 2013 at 03:52:31PM -0400, Jeff King wrote:\n>> On Mon, Sep 09, 2013 at 11:47:45AM -0700, Junio C Hamano wrote:\n>>\n>> > You are in favor of an _option_ to allow people to forbid a pull in\n>> > a non-ff situation, and I think other people are also in\n>> > agreement. So perhaps:\n>> >\n>> > - drop jc/pull-training-wheel and revert its merge from 'next';\n>> >\n>> > - update Felipe's series with a bit of tweak to make it less\n>> > impactful by demoting error into warning and advice.\n>> >\n>> > would be a good way forward?\n>>\n>> I think that would address the concern I raised, because it does not\n>> create a roadblock to new users accomplishing their task. They can\n>> ignore the warning, or choose \"merge\" as the default to shut up the\n>> warning (and it is easy to choose that if you are confused, because it\n>> is what git is doing by default alongside the warning).\n>\n> I think we need to make sure that we give instructions for how to go\n> back if the default hasn't done what you wanted. Something like this:\n>\n> Your pull did not fast-forward, so Git has merged '$upstream' into\n> your branch, which may not be correct for your project. If you\n> would rather rebase your changes, run\n>\n> git rebase\n>\n> See \"pull.mode\" in git-config(1) to suppress this message in the\n> future.\n\nAnd you propose to show that every single time the user does a 'git\npull'' that results in a non-fast-forward merge? Isn't that what 'git\npull --help' is for?\n\n-- \nFelipe Contreras\n"},{"id":"227285","messageId":"CAMP44s0YaQo7xAkPcV3xVTcYQStUVuyY=we-=KMgtZ-xgZzz1Q@mail.gmail.com","threadId":"34821","inReplyTo":"vpqr4cy4g5q.fsf@anie.imag.fr","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-09-09T23:17:07Z","receivedAt":"2013-09-09T23:17:07Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Mon, Sep 9, 2013 at 2:18 AM, Matthieu Moy\n wrote:\n> Felipe Contreras writes:\n>\n>> On Sun, Sep 8, 2013 at 7:01 PM, brian m. carlson\n>> wrote:\n>>\n>>> Yes, that would be me. My hesitance here is that as the one usually\n>>> driving git updates (which so far have happened once a year), I will end\n>>> up retraining forty developers. I don't think the current behavior is\n>>> broken or really problematic at all: merging has always been the\n>>> default, and people have come to expect that.\n>>\n>> It may not be broken for you, but it is for other people. Would you be\n>> so egocentric as to ignore everybody else because \"it works for you\"?\n>\n> It's not a matter of \"works for me\". Git currently \"works\" for all use\n> cases because you can already merge or rebase. The proposed changes are\n> not about allowing the behavior that works, but disallowing the behavior\n> that doesn't.\n\nIf it works for all use cases why are we discussing this?\n\nHint: because it doesn't.\n\n> I agree that allowing people to reject non-ff merge is a good idea.\n>\n> I strongly disagree that this should eventually become the default,\n> though. I think it should really remain an opt-in (possibly with some\n> non-scary warning advertizing for the feature).\n\nThat defeats the whole purpose of the proposal, which means that you\ndon't understand the problem.\n\nThe problem is the newcomers, and the newcomers will most definitely\nnot activate a configuration option to tell them that they are doing\nsomething potentially undesirable.\n\nBy the time they learn about pull.mode, they probably already know\nwhat a rebase is. So what is the point of the configuration in the\nfirst place?\n\n> First, the discussions on this thread show that it's hard to find the\n> right behavior. My guess is that it's hard because we're trying to think\n> for the users. I've used GNU Arch for a while, and this VCS was trying\n> to impose what the developer thought was good for me. I had to fight\n> with the tool whenever I tried to do something \"non-standard\". I don't\n> want to go back there. Preventing _users_ to do something because _we_\n> considered it was bad for them is wrong IMHO.\n\nWe are not preventing anybody from anything. The user can do 'git pull\n--merge', the user can set 'pull.mode = merge', the user can do\nanything he wants.\n\n> I already mentionned another reason in\n> http://thread.gmane.org/gmane.comp.version-control.git/225146/focus=229162 :\n> \"git rebase\" is hard to use for many people. With \"git merge\", doing\n> things wrong isn't so bad. If you forget to commit after a conflicted\n> merge, you'll mix your changes with the merge, this is bad, but it\n> works. With \"git rebase\", if you forget to \"git rebase --continue\" after\n> a conflict, you end up in detached HEAD, with part of your own changes\n> discarded. If my students end up in this situation, they'll stop using\n> Git and exchange files by email.\n\nThat doesn't mean anything, you are assuming the user will do 'git\npull --rebase', and there's no rationale as to why they would end up\ndoing that.\n\n> \"git pull\" is one of the first things one learns with Git, and\n> _requiring_ users to chose between merge and rebase is a nonsense at\n> this time of learning.\n\nLet's use another core command as an illustration.\n\n'git commit' by default \"prevents\" users from creating commits without\nfirst adding changes to the staging area, and since it's a concept\nunique to Git, it's fair to say that none of the newcomers understand\nwhy 'git commit' is failing, the error messages is not particularly\nuseful either.\n\nFollowing your rationale, by default 'git commit' should behave like\n'git commit --all', and add all the changes in the work tree to the\nnew commit when there's no changes in the staging area, that would be\nthe easiest for the newcomers, but we don't do that, we \"force\" them\nto understand what the staging area is, or do 'git commit --all', most\nof the newcomers do the later.\n\nSo, if we draw a parallel with with pull, 'git pull --merge' is like\n'git commit --all'; if they don't know what they are doing, that's\nwhat they should type, and when the pull is non-fast-forward we error\nout, just like we error out when there's nothing on the staging area.\n\n-- \nFelipe Contreras\n"},{"id":"227307","messageId":"20130910080834.GL2582@serenity.lan","threadId":"34821","inReplyTo":"CAMP44s0y-cpEWuPTQSwC-Hyp-RNcwdyDRTbAsUewH5bAPPMXuQ@mail.gmail.com","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2013-09-10T08:08:34Z","receivedAt":"2013-09-10T08:08:34Z","isPatch":true,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Mon, Sep 09, 2013 at 06:02:35PM -0500, Felipe Contreras wrote:\n> On Mon, Sep 9, 2013 at 3:24 PM, John Keeping wrote:\n> > On Mon, Sep 09, 2013 at 03:52:31PM -0400, Jeff King wrote:\n> >> On Mon, Sep 09, 2013 at 11:47:45AM -0700, Junio C Hamano wrote:\n> >>\n> >> > You are in favor of an _option_ to allow people to forbid a pull in\n> >> > a non-ff situation, and I think other people are also in\n> >> > agreement. So perhaps:\n> >> >\n> >> > - drop jc/pull-training-wheel and revert its merge from 'next';\n> >> >\n> >> > - update Felipe's series with a bit of tweak to make it less\n> >> > impactful by demoting error into warning and advice.\n> >> >\n> >> > would be a good way forward?\n> >>\n> >> I think that would address the concern I raised, because it does not\n> >> create a roadblock to new users accomplishing their task. They can\n> >> ignore the warning, or choose \"merge\" as the default to shut up the\n> >> warning (and it is easy to choose that if you are confused, because it\n> >> is what git is doing by default alongside the warning).\n> >\n> > I think we need to make sure that we give instructions for how to go\n> > back if the default hasn't done what you wanted. Something like this:\n> >\n> > Your pull did not fast-forward, so Git has merged '$upstream' into\n> > your branch, which may not be correct for your project. If you\n> > would rather rebase your changes, run\n> >\n> > git rebase\n> >\n> > See \"pull.mode\" in git-config(1) to suppress this message in the\n> > future.\n> \n> And you propose to show that every single time the user does a 'git\n> pull'' that results in a non-fast-forward merge? Isn't that what 'git\n> pull --help' is for?\n\nOnly if the user has not given an explicit mode (either on the command\nline or in their config) and possibly if an advice.pullNonFF variable is\nnot set to false. I think that matches what Git does elsewhere.\n\ngit-pull(1) provides quite a lot more information that I think a new Git\nuser would be comfortable with. There certainly is not a quick way to\nfind out how to fix this error and I don't think it makes sense to add\none because we'll still be presenting the user with all of the other\ncontent and they won't have any way to know what they can safely ignore\nand what they have to read and understand.\n"},{"id":"227310","messageId":"vpq4n9tjd5z.fsf@anie.imag.fr","threadId":"34821","inReplyTo":"CAMP44s0YaQo7xAkPcV3xVTcYQStUVuyY=we-=KMgtZ-xgZzz1Q@mail.gmail.com","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-09-10T08:26:00Z","receivedAt":"2013-09-10T08:26:00Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Felipe Contreras writes:\n\n> The problem is the newcomers, and the newcomers will most definitely\n> not activate a configuration option to tell them that they are doing\n> something potentially undesirable.\n\nI teach Git to 200 newcommers each year. All of them run \"git pull\" the\nfirst day, but believe me, very few of them want to know what a rebase\nis at that time.\n\n(I also work with experienced computer scientists, and actually, very\nfew of them want to know what a rebase is either :-( )\n\n> By the time they learn about pull.mode, they probably already know\n> what a rebase is. So what is the point of the configuration in the\n> first place?\n[...]\n> That doesn't mean anything, you are assuming the user will do 'git\n> pull --rebase', and there's no rationale as to why they would end up\n> doing that.\n\nSo, you insist in asking the user to chose between rebase and merge, but\nyou also insist that they will not chose rebase? So, why ask?\n\n> 'git commit' by default \"prevents\" users from creating commits without\n> first adding changes to the staging area, and since it's a concept\n> unique to Git, it's fair to say that none of the newcomers understand\n> why 'git commit' is failing, the error messages is not particularly\n> useful either.\n\nI don't particularly agree that not defaulting to --all was a good idea,\nbut that's another topic.\n\nBut the error message is rather clear:\n\n no changes added to commit (use \"git add\" and/or \"git commit -a\")\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"227373","messageId":"xmqqfvtcwdb3.fsf@gitster.dls.corp.google.com","threadId":"34821","inReplyTo":"vpqbo41lo2v.fsf@anie.imag.fr","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-09-10T21:56:48Z","receivedAt":"2013-09-10T21:56:48Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\n> Junio C Hamano writes:\n>\n>> You are in favor of an _option_ to allow people to forbid a pull in\n>> a non-ff situation, and I think other people are also in\n>> agreement.\n>\n> Yes. Having an option can't harm anybody, and there's a clear demand for\n> that.\n>\n>> So perhaps:\n>>\n>> - drop jc/pull-training-wheel and revert its merge from 'next';\n>>\n>> - update Felipe's series with a bit of tweak to make it less\n>> impactful by demoting error into warning and advice.\n>>\n>> would be a good way forward?\n>\n> I didn't follow very closely the discussions and patch series, but that\n> would sound right to me. The last version of Felipes' patch series\n> already gives a warning only, but the wording and commit message implies\n> that this will become an error in the future (this is the part with\n> which I disagree).\n\nOK, the first step to drop jc/pull-training-wheel from 'next' has\nbeen done. I _think_ the one that starts at $gmane/234295 is the\nnewer incarnation of the patches in this thread, but that seems to\ndo a lot more than what the patches in this thread did, and it also\nbadly interacts with another topic in flight that updates git-pull,\nso I have a topic branch for it but haven't merged to 'pu' yet.\n"},{"id":"227440","messageId":"CAMP44s2dmn48T=c6aSLrWeTY=CKf5AYnAv7gA8bLjLMyb9-MTA@mail.gmail.com","threadId":"34821","inReplyTo":"vpq4n9tjd5z.fsf@anie.imag.fr","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-09-11T10:53:44Z","receivedAt":"2013-09-11T10:53:44Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, Sep 10, 2013 at 3:26 AM, Matthieu Moy\n wrote:\n> Felipe Contreras writes:\n>\n>> The problem is the newcomers, and the newcomers will most definitely\n>> not activate a configuration option to tell them that they are doing\n>> something potentially undesirable.\n>\n> I teach Git to 200 newcommers each year. All of them run \"git pull\" the\n> first day, but believe me, very few of them want to know what a rebase\n> is at that time.\n\nAnd who says they have to? This is a straw man argument.\n\nMay of them don't want to know what the staging area is, that's why\nthey run 'git commit --all', and just like that they can run 'git pull\n--merge'.\n\n>> By the time they learn about pull.mode, they probably already know\n>> what a rebase is. So what is the point of the configuration in the\n>> first place?\n> [...]\n>> That doesn't mean anything, you are assuming the user will do 'git\n>> pull --rebase', and there's no rationale as to why they would end up\n>> doing that.\n>\n> So, you insist in asking the user to chose between rebase and merge, but\n> you also insist that they will not chose rebase? So, why ask?\n\nBecause as you said, they don't know what that is.\n\n>> 'git commit' by default \"prevents\" users from creating commits without\n>> first adding changes to the staging area, and since it's a concept\n>> unique to Git, it's fair to say that none of the newcomers understand\n>> why 'git commit' is failing, the error messages is not particularly\n>> useful either.\n>\n> I don't particularly agree that not defaulting to --all was a good idea,\n> but that's another topic.\n\nIt the same topic, the project already made a choice, and precisely\nbecause of the same reasoning that 'git commit --all' is required,\n'git pull --merge' should be required.\n\n> But the error message is rather clear:\n>\n> no changes added to commit (use \"git add\" and/or \"git commit -a\")\n\nAnd we can do the same:\n\n\"Read more with 'git pull --help' or do 'git pull --merge'.\"\n\n-- \nFelipe Contreras\n"},{"id":"227445","messageId":"vpqbo3za8r9.fsf@anie.imag.fr","threadId":"34821","inReplyTo":"CAMP44s2dmn48T=c6aSLrWeTY=CKf5AYnAv7gA8bLjLMyb9-MTA@mail.gmail.com","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-09-11T11:38:18Z","receivedAt":"2013-09-11T11:38:18Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Felipe Contreras writes:\n\n> On Tue, Sep 10, 2013 at 3:26 AM, Matthieu Moy\n> wrote:\n>\n>> So, you insist in asking the user to chose between rebase and merge, but\n>> you also insist that they will not chose rebase? So, why ask?\n>\n> Because as you said, they don't know what that is.\n\nThat does not answer my question: why ask?\n\nLook around you what people say about Git. See how many complain about\nGit not exposing enough complexity to the user. See how many would\ncomplain about Git not advertising rebase enough. Then, look how many\ncomplain about Git exposing too much complexity and making it too easy\nto use features like rebase.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"227597","messageId":"CAMP44s2z4HBR+qpVbbCmTR-OrAK_eMH4CfSfofFDuarLKP7RPA@mail.gmail.com","threadId":"34821","inReplyTo":"vpqbo3za8r9.fsf@anie.imag.fr","subject":"Re: [PATCH 0/3] Reject non-ff pulls by default","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-09-13T00:55:00Z","receivedAt":"2013-09-13T00:55:00Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Wed, Sep 11, 2013 at 6:38 AM, Matthieu Moy\n wrote:\n> Felipe Contreras writes:\n>\n>> On Tue, Sep 10, 2013 at 3:26 AM, Matthieu Moy\n>> wrote:\n>>\n>>> So, you insist in asking the user to chose between rebase and merge, but\n>>> you also insist that they will not chose rebase? So, why ask?\n>>\n>> Because as you said, they don't know what that is.\n>\n> That does not answer my question: why ask?\n\nIf you have to ask, then you haven't read the commit messages, the\ncover letter, or the relevant discussion. Even Linus Torvalds agreed\nthis was a good change.\n\n> Look around you what people say about Git. See how many complain about\n> Git not exposing enough complexity to the user. See how many would\n> complain about Git not advertising rebase enough. Then, look how many\n> complain about Git exposing too much complexity and making it too easy\n> to use features like rebase.\n\nAnd see how many are confused by Git doing something they never told\nit to do, and then being totally lost because they are in the middle\nof a state they don't understand, and how many do merges by mistake.\n\nThere's a reason why Git user-base considers 'git pull' dangerous.\n\n-- \nFelipe Contreras\n"}]}