{"thread":{"id":"59190","subject":"Defaulting --rebase-merges overall?","startedAt":"2023-02-03T18:19:16Z","lastAt":"2023-02-03T21:10:24Z","messageCount":2,"participants":["Tao Klerks","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"471454","messageId":"CAPMMpoj6E-85a59EaHD2aR_oKA=_u78qRV+wp8mqXkR39KctmA@mail.gmail.com","threadId":"59190","inReplyTo":null,"subject":"Defaulting --rebase-merges overall?","fromName":"Tao Klerks","fromEmail":"tao@klerks.biz","sentAt":"2023-02-03T18:19:00Z","receivedAt":"2023-02-03T18:19:16Z","isPatch":false,"sender":{"key":"tao@klerks.biz","avatar":"https://avatars.githubusercontent.com/u/531704?v=4"},"body":"Hi folks,\n\nI've had a couple of users recently be bitten by \"git rebase\"'s\ndefault handling of merge commits:\n\n* One user had selected the \"git config pull.rebase true\" option from\nthe \"Need to specify how to reconcile divergent branches\" pull\nconflict hint text, without understanding enough about what that\nmeant: that if they do a \"pull\" right after having done a (non-ff)\n\"merge\", their commit history would get mangled with a set of\nduplicated commits.\n\n* The other was using a GUI (Intellij IDEA), which offered to rebase\nwhen there was a push conflict, but didn't mention or do anything\nspecial about the fact that the single commit to be rebased on a push\nconflict was a merge commit (same consequences)\n\nIn terms of \"quick wins\" to help these users avoid the trap they fell\ninto, I can think of two \"quick wins\":\n1. Change the \"Need to specify how to reconcile divergent branches\"\npull conflict hint text to offer \"git config pull.rebase merges\"\ninstead of \"git config pull.rebase true\"\n2. Offer a global \"--rebase-merges by default\" config option (I know\nthere is already a per-branch option, but that's really not very\neffective when people are creating new branches all the time)\n\nI've scanned the archives of the last year or two and can't find any\nchatter or activity around this - does anyone have an opinion\nregarding either of these approaches?\n\nIdeally I'd like to do both. The hint change for people who follow the\nhint without understanding the dangers, and the global config option\nfor people who understand this historical weirdness of rebase and\nwould rather see the back of it, now that \"--rebase-merges\" exists and\nimproves rebase behavior for most users under most circumstances.\nPresumably with such a global config option we would also need a\n\"--no-rebase-merges\" option to counter its effect on-demand?\n\nAs I think about it, the global option sounds like it might be hard to\nprove the correctness of (and compatibility with the hosts of other\noptions), so I probably won't be qualified to do this. Is there any\nobjection to the simple hint change, at least?\n\nThanks,\nTao\n"},{"id":"471459","messageId":"xmqqa61uo3q0.fsf@gitster.g","threadId":"59190","inReplyTo":"CAPMMpoj6E-85a59EaHD2aR_oKA=_u78qRV+wp8mqXkR39KctmA@mail.gmail.com","subject":"Re: Defaulting --rebase-merges overall?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-02-03T21:09:59Z","receivedAt":"2023-02-03T21:10:24Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Tao Klerks <tao@klerks.biz> writes:\n\n> 1. Change the \"Need to specify how to reconcile divergent branches\"\n> pull conflict hint text to offer \"git config pull.rebase merges\"\n> instead of \"git config pull.rebase true\"\n> ...\n> As I think about it, the global option sounds like it might be hard to\n> prove the correctness of (and compatibility with the hosts of other\n> options), so I probably won't be qualified to do this. Is there any\n> objection to the simple hint change, at least?\n\nI think suggesting \"[pull] rebase = merges\" is more in line with the\noriginal spirit of suggesting \"you want to recreate your work on top\nof the updated upstream\".\n\nI do not particularly find it a good idea to suggest configuring\n\"git pull\" to always rebase (whether it rebases with mergesor\nflattens) in the first place, but if we were to offer such an option\nanyway, \"merges\" is a much better choice than \"true\" to flatten,\nsimply because that matches the goal of \"to recreate your work on\ntop of the updated upstream\" better.\n\nThe only reason why 'true' is in the suggestion is because 'merges'\ncame much later than \"when tried to pull and got a conflict, you'd\nrebuild your work on top of theirs\" suggestion was introduced.\n"}]}