{"thread":{"id":"59200","subject":"[PATCH] pull: conflict hint pull.rebase suggestion should offer \"merges\" vs \"true\"","startedAt":"2023-02-05T16:24:42Z","lastAt":"2023-03-01T12:46:51Z","messageCount":34,"participants":["Tao Klerks via GitGitGadget","Alex Henrie","Tao Klerks","Junio C Hamano","Elijah Newren","Phillip Wood","Sergey Organov","Felipe Contreras"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"471528","messageId":"pull.1474.git.1675614276549.gitgitgadget@gmail.com","threadId":"59200","inReplyTo":null,"subject":"[PATCH] pull: conflict hint pull.rebase suggestion should offer \"merges\" vs \"true\"","fromName":"Tao Klerks via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2023-02-05T16:24:36Z","receivedAt":"2023-02-05T16:24:42Z","isPatch":true,"sender":{"key":"tao@klerks.biz","avatar":"https://avatars.githubusercontent.com/u/531704?v=4"},"body":"From: Tao Klerks \n\nWhen \"git pull\" is called without a conflict-handling instruction or\nconfiguration, it displays a hint proposing \"pull.rebase\" and \"pull.ff\"\nconfig options for future handling.\n\nThe hint offers three permanent settings, \"merge\", rebase\", and \"ff\". The\nproposed command for \"rebase\" is \"git config pull.rebase true\".\n\nUnfortunately, this rebase configuration can easily lead to non-expert users\naccidentally rebasing not their own commits, instead others' commits, if the\nnew commits they have locally before the \"pull\" include a merge of another\nbranch, eg \"main\".\n\nSince 2018 in git version \"2.18\", it has supported a new rebase flag\n\"--rebase-merges\", with corresponding pull.rebase config option \"merges\".\nThis new option is ideal for rebasing local work on \"pull\", as it will\nnot \"mangle\"/flatten any local merge commits but rather recreate them.\n\nChange the pull conflict hint text to propose \"pull.rebase merges\" instead\nof \"pull.rebase true\", and \"git pull --rebase=merges\" instead of\n\"git pull --rebase\".\n\nSigned-off-by: Tao Klerks \n---\n pull: conflict hint pull.rebase suggestion should offer \"merges\" vs\n \"true\"\n \n Hint change as proposed in\n https://lore.kernel.org/git/xmqqa61uo3q0.fsf@gitster.g/\n\nPublished-As: https://github.com/gitgitgadget/git/releases/tag/pr-1474%2FTaoK%2Ftao-fetch-rebase-hint-v1\nFetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1474/TaoK/tao-fetch-rebase-hint-v1\nPull-Request: https://github.com/gitgitgadget/git/pull/1474\n\n builtin/pull.c | 8 ++++----\n 1 file changed, 4 insertions(+), 4 deletions(-)\n\ndiff --git a/builtin/pull.c b/builtin/pull.c\nindex 1ab4de0005d..535364fbb07 100644\n--- a/builtin/pull.c\n+++ b/builtin/pull.c\n@@ -967,13 +967,13 @@ static void show_advice_pull_non_ff(void)\n \t\t \"your next pull:\\n\"\n \t\t \"\\n\"\n \t\t \" git config pull.rebase false # merge\\n\"\n-\t\t \" git config pull.rebase true # rebase\\n\"\n+\t\t \" git config pull.rebase merges # rebase\\n\"\n \t\t \" git config pull.ff only # fast-forward only\\n\"\n \t\t \"\\n\"\n \t\t \"You can replace \\\"git config\\\" with \\\"git config --global\\\" to set a default\\n\"\n-\t\t \"preference for all repositories. You can also pass --rebase, --no-rebase,\\n\"\n-\t\t \"or --ff-only on the command line to override the configured default per\\n\"\n-\t\t \"invocation.\\n\"));\n+\t\t \"preference for all repositories. You can also pass --rebase=merges,\\n\"\n+\t\t \"--no-rebase, or --ff-only on the command line to override the configured\\n\"\n+\t\t \"default per invocation.\\n\"));\n }\n \n int cmd_pull(int argc, const char **argv, const char *prefix)\n\nbase-commit: a6a323b31e2bcbac2518bddec71ea7ad558870eb\n-- \ngitgitgadget\n"},{"id":"472184","messageId":"CAMMLpeTPEoKVTbfc17w+Y9qn7jOGmQi_Ux0Y3sFW5QTgGWJ=SA@mail.gmail.com","threadId":"59200","inReplyTo":"pull.1474.git.1675614276549.gitgitgadget@gmail.com","subject":"Re: [PATCH] pull: conflict hint pull.rebase suggestion should offer \"merges\" vs \"true\"","fromName":"Alex Henrie","fromEmail":"alexhenrie24@gmail.com","sentAt":"2023-02-16T03:22:00Z","receivedAt":"2023-02-16T03:22:15Z","isPatch":true,"sender":{"key":"alexhenrie24@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5951993?v=4"},"body":"On Sun, Feb 5, 2023 at 9:41 AM Tao Klerks via GitGitGadget\n wrote:\n>\n> From: Tao Klerks \n>\n> When \"git pull\" is called without a conflict-handling instruction or\n> configuration, it displays a hint proposing \"pull.rebase\" and \"pull.ff\"\n> config options for future handling.\n>\n> The hint offers three permanent settings, \"merge\", rebase\", and \"ff\". The\n> proposed command for \"rebase\" is \"git config pull.rebase true\".\n>\n> Unfortunately, this rebase configuration can easily lead to non-expert users\n> accidentally rebasing not their own commits, instead others' commits, if the\n> new commits they have locally before the \"pull\" include a merge of another\n> branch, eg \"main\".\n>\n> Since 2018 in git version \"2.18\", it has supported a new rebase flag\n> \"--rebase-merges\", with corresponding pull.rebase config option \"merges\".\n> This new option is ideal for rebasing local work on \"pull\", as it will\n> not \"mangle\"/flatten any local merge commits but rather recreate them.\n>\n> Change the pull conflict hint text to propose \"pull.rebase merges\" instead\n> of \"pull.rebase true\", and \"git pull --rebase=merges\" instead of\n> \"git pull --rebase\".\n>\n> Signed-off-by: Tao Klerks \n> ---\n> pull: conflict hint pull.rebase suggestion should offer \"merges\" vs\n> \"true\"\n>\n> Hint change as proposed in\n> https://lore.kernel.org/git/xmqqa61uo3q0.fsf@gitster.g/\n>\n> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1474%2FTaoK%2Ftao-fetch-rebase-hint-v1\n> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1474/TaoK/tao-fetch-rebase-hint-v1\n> Pull-Request: https://github.com/gitgitgadget/git/pull/1474\n>\n> builtin/pull.c | 8 ++++----\n> 1 file changed, 4 insertions(+), 4 deletions(-)\n>\n> diff --git a/builtin/pull.c b/builtin/pull.c\n> index 1ab4de0005d..535364fbb07 100644\n> --- a/builtin/pull.c\n> +++ b/builtin/pull.c\n> @@ -967,13 +967,13 @@ static void show_advice_pull_non_ff(void)\n> \"your next pull:\\n\"\n> \"\\n\"\n> \" git config pull.rebase false # merge\\n\"\n> - \" git config pull.rebase true # rebase\\n\"\n> + \" git config pull.rebase merges # rebase\\n\"\n> \" git config pull.ff only # fast-forward only\\n\"\n> \"\\n\"\n> \"You can replace \\\"git config\\\" with \\\"git config --global\\\" to set a default\\n\"\n> - \"preference for all repositories. You can also pass --rebase, --no-rebase,\\n\"\n> - \"or --ff-only on the command line to override the configured default per\\n\"\n> - \"invocation.\\n\"));\n> + \"preference for all repositories. You can also pass --rebase=merges,\\n\"\n> + \"--no-rebase, or --ff-only on the command line to override the configured\\n\"\n> + \"default per invocation.\\n\"));\n\nHi Tao, thank you for sharing your experiences with non-experts using\n`git pull`. I am always curious to see how people who are learning Git\nreact to it, and I am very interested in making Git as straightforward\nas possible.\n\nI'm afraid I have several objections to this patch...\n\n- The proposed wording is likely to further confuse novices. It's\nasking the user to choose between the reconciliation strategies of\nmerging and rebasing, but then says to use the unintuitive combination\n\"rebase=merges\" which sounds like it's going to make a merge commit at\nthe end of the branch anyway.\n\n- The proposed wording makes it sound like there's something wrong\nwith doing a regular rebase, but that's not usually the case because\nin practice a regular rebase is almost always equivalent to\nrebase=merges. A regular rebase may even be what the user really\nwants: For example, the user might choose to merge when pulling and\nthen change their mind and decide that they really wanted to rebase.\nRepeating the pull with the regular -r or --rebase flag fixes the\nmistake.\n\n- `git pull -ri` (or its longer form `git pull --rebase=interactive`)\nis generally more useful than `git pull --rebase=merges`, but once\nrebase=merges has been specified, there's no way to specify\nrebase=interactive also. Recommending rebase=merges steers people away\nfrom rebase=interactive, hiding useful functionality from the user.\n\nNow, this is not to say that there's no room for improvement. I like\nthe rebase=merges option and I wish everyone knew about it because\nthere are situations where it really is the best option. I suggest\nleaving the existing text alone, but adding an additional paragraph,\nsomething like:\n\nNote that --rebase or pull.rebase=true will drop existing merge\ncommits and rebase all of the commits from all of the merged branches.\nIf you want to rebase but preserve existing merge commits, use\n--rebase=merges or pull.rebase=merges instead.\n\n-Alex\n"},{"id":"472194","messageId":"CAPMMpogFAR6cvcR8T5fx+AoytAJ7TsPpSeOjHNzW4Gmkuq7FLQ@mail.gmail.com","threadId":"59200","inReplyTo":"CAMMLpeTPEoKVTbfc17w+Y9qn7jOGmQi_Ux0Y3sFW5QTgGWJ=SA@mail.gmail.com","subject":"Re: [PATCH] pull: conflict hint pull.rebase suggestion should offer \"merges\" vs \"true\"","fromName":"Tao Klerks","fromEmail":"tao@klerks.biz","sentAt":"2023-02-16T12:31:17Z","receivedAt":"2023-02-16T12:31:33Z","isPatch":true,"sender":{"key":"tao@klerks.biz","avatar":"https://avatars.githubusercontent.com/u/531704?v=4"},"body":"On Thu, Feb 16, 2023 at 4:22 AM Alex Henrie wrote:\n>\n> - The proposed wording is likely to further confuse novices. It's\n> asking the user to choose between the reconciliation strategies of\n> merging and rebasing, but then says to use the unintuitive combination\n> \"rebase=merges\"\n\nMy thesis, which you clearly disagree with, is that for this type of\nsituation, \"rebase=merges\" is not an \"unintuitive combination\", but\nrather is \"a plain and simple rebase\". It is truly unfortunate that\ngit's history has led us to a place where this command is so awkwardly\nnamed, I agree with that at least.\n\nIf there's an appetite for it, I would love to contribute to a\nmulti-year adventure to change git's behavior, little by little, until\nthe behavior of \"rebase=merges\" is the default, and the old behavior\nbecomes a different option like\n\"rebase=copy-merged-commits-to-flatten\"\n\n> which sounds like it's going to make a merge commit at\n> the end of the branch anyway.\n\nI can't quite tell whether you're referring to the naming of the\noption (which I agree, sucks), or saying that it sounds *to you* like\nit will make a merge commit. It will not make a merge commit unless\n*you* previously made a merge commit. It will rebase your merge\ncommits, only if there are any that should be rebased.\n\nIf your concern is that we shouldn't be showing anyone the\n\"consistently reasonable rebase option\" because it's confusingly named\nwrt the \"rebase option that experts understand and has a shorter\nname\", then let's figure out how to rename it. In the meantime, let's\nhelp avoid people shooting themselves in the foot. A hint pointing at\nthe cool loaded gun lying on the mantelpiece is *not* helping users\navoid shooting themselves in the foot.\n\n>\n> - The proposed wording makes it sound like there's something wrong\n> with doing a regular rebase, but that's not usually the case because\n> in practice a regular rebase is almost always equivalent to\n> rebase=merges.\n\nThe new proposed option will do the right thing in (almost?) all\ncases. The previous option will make a horrible mess of things in some\n(or, depending on the workflow, many!) cases.\n\nIn all the cases where the behavior is equivalent, that's great. In\nalmost all the cases where the behavior is different, the proposed new\nbehavior is superior (to anyone who needs that hint).\n\nThere is only one case that I know of in which the proposed new\nbehavior could be considered marginally worse:\n\n* I have a local branch \"feature-1\", with some local work on it\n* This is a shared branch, others are working on it also, so\n\"origin/feature-1\" has a few other commits on it also (diverged)\n* I create a derived branch, \"feature-1-sub\". I do some work on it\n* I pull with rebase (--rebase or --rebase=merges, makes no\ndifference), so my original local feature-1 changes are rebased on top\nof others' changes.\n* I do some more work on (my local, rebased) \"feature-1\"\n* I merge \"feature-1-sub\" into \"feature-1\"\n** -> I now have duplicate commits in my history: the original local\n\"feature-1\" work is in the history of \"feature-1-sub\", and it was/is\nseparately rebased in \"feature-1\"\n* I \"git pull --rebase\" or \"git pull --rebase=merges\":\n** A \"simple rebase\" will automatically squash the duplicated commit(s)\n** A \"rebase with rebase-merges\" will retain/recreate the merge\ncommit, and thereby retain the existence of a duplicated commit in the\ncommit graph.\n(test script available upon request, I didn't want to spam the list with it)\n\nWhile I agree \"--rebase=merges\" is not clearly superior, or could even\nbe worse in this one contrived case, I would argue that this is far\nless harmful than the current \"pathological case\" of \"--rebase\", which\nwill happen far more easily and which I will outline again:\n\n* There is a \"main\" branch with lots of commit activity from lots of\ncontributors\n* There is a \"feature-1\" branch with a few contributors collaborating\non something that will be merged into \"main\" when ready\n* These contributors are not experts - they don't coordinate on\nrebasing \"feature-1\" every time they need to incorporate changes from\n\"main\" - instead, they merge \"main\" into \"feature-1\" when that's\nneeded\n* One of those contributors is tasked with doing the merge from main,\nresolving conflicts, spot-checking, etc - the last merge from main was\n10 days ago, 100 commits.\n* They have a merge commit ready, tested\n* They try to push \"feature-1\", but one of the other contributors has\nadded some work/commits, so the error tells them to \"git pull\" first\n* They \"git pull\", get an error and follow the wrong advice, or they\nfollowed the wrong advice in the preceding days/weeks - they end up\ndoing a \"git pull --rebase\" without knowing what that means for their\nrecent merge commit, and/or without even realizing that's how they\npreviously configured things\n* Their \"feature-1\" branch now has 100 duplicated commits by arbitrary\n\"main\" developers, but they haven't even necessarily noticed - they\nmay well be using a GUI that just congratulates them on a successful\npull\n* They now push, successfully.\n* Unless anyone looks at the commit graph of \"feature-1\" carefully,\nno-one necessarily notices anything is wrong; the changes from \"main\"\nare in \"feature-1\", as expected; it's just the lines connecting them\nthat are wrong\n* Two weeks later, the team needs to merge in \"main\" again - and they\nstart to get all sorts of weird conflicts\n** \"Oh man, git sucks - I thought it was supposed to merge *better*\nthan that other stuff, but it's finding conflicts that have nothing to\ndo with us, all over the place!\"\n** \"Hmm, this is weird - let's see what the git expert says\"\n** \"Oh man, 'feature-1' needs to be rebuilt, and everyone working on\nit needs to figure out how to rebase their work / their branch(es)\nonto the new state\"\n** etc\n\n> A regular rebase may even be what the user really\n> wants: For example, the user might choose to merge when pulling and\n> then change their mind and decide that they really wanted to rebase.\n> Repeating the pull with the regular -r or --rebase flag fixes the\n> mistake.\n\nI don't understand the relevance of this example: No-one is suggesting\nto forbid \"merge-flattening rebases\" - only avoiding the suggestion to\nuse them as the default for people who don't know what they are doing\n(that's who the hints are *for*!)\n\nThe way you suggest this example, it feels like you think this might\nbe intuitive/predictable: \"I chose the wrong thing, so I flip the\nchoice and I get the other outcome\" - that's not true at all, because\nif you flip the choice the other way (--rebase first, and then merge),\nyou get a completely different outcome! (especially if what you\naccidentally rebased contained a merge of course - but even without\nmerges in the rebased history, doing a merge later does not yield\nnearly the same outcome).\n\n>\n> - `git pull -ri` (or its longer form `git pull --rebase=interactive`)\n> is generally more useful than `git pull --rebase=merges`, but once\n> rebase=merges has been specified, there's no way to specify\n> rebase=interactive also. Recommending rebase=merges steers people away\n> from rebase=interactive, hiding useful functionality from the user.\n\nI don't understand your argument here... Are you saying that users\nreading \"You can also pass --rebase\" would have been more likely to\nend up running \"--rebase=interactive\" than users reading \"You can also\npass --rebase=merges\"? I believe this to be a grave misreading of user\nbehavior, but I have no credentials to back up this belief.\n\nPeople consistently, and unhesitantly, copy-paste the suggestions\noffered to them. If you believe users should be running\n\"--rebase=interactive\", then the new wording is no worse than the old.\n\nNow, as to whether users should in fact typically be running\n\"--rebase=interactive\" when doing a \"git pull\" - is there an option to\n\"preserve merges\" in this interaction? For users who *do not ever\nmerge* your suggestion sounds... possibly-overbearing, but not wrong.\nFor users who *do* merge, it is plain wrong as far as I know.\n\n>\n> Now, this is not to say that there's no room for improvement. I like\n> the rebase=merges option and I wish everyone knew about it because\n> there are situations where it really is the best option. I suggest\n> leaving the existing text alone, but adding an additional paragraph,\n> something like:\n>\n> Note that --rebase or pull.rebase=true will drop existing merge\n> commits and rebase all of the commits from all of the merged branches.\n> If you want to rebase but preserve existing merge commits, use\n> --rebase=merges or pull.rebase=merges instead.\n\nMy primary motivation with this pull request is to reduce the\nincidences, out there in the world, of people copy-pasting \"git config\npull.rebase true\" into their command-line, and causing themselves\nmajor headaches days or weeks later. The \"--rebase=interactive\" part\nis secondary (to my concerns), because it's much less copy-pastable.\n\nYour proposal does nothing for my concern, unfortunately - it leaves a\nmessage that, overall, offers three copy-pastable options, two of\nwhich are safe-enough, and one of which has substantial chances of\nplunging you into a world of pain that you cannot comprehend. It is\nplain wrong. We need to change it.\n\nI am very happy to add the paragraph you proposed instead of changing\n\"--rebase\" to \"--rebase=interactive\", but I would like to see a much\nbetter suggestion as to how to address the harm of \"git config\npull.rebase true\".\n\n\nThanks for your feedback, and my apologies for the insistent response\n- I'm having a hard time figuring out how to express just how *bad*\nthe existing copy-pastable suggestion in this hint is (in this day and\nage), for users who merge - users who, I believe, make up the\nsignificant majority of \"corporate\" developers at the very least, and\nI suspect even the significant majority of git users out in the world.\n\nI'm adding Johannes Schindelin to the thread in case he has the cycles\nto weigh in - as the original author of what I would call \"the better\nway\" (5 years ago now!), I'm sure he's more aware than most of its\nlimitations, and of any reasons why we *wouldn't* want to make the\nchange(s) I've suggested here.\n\nThanks,\nTao\n"},{"id":"472248","messageId":"CAMMLpeTQ1RpsvwRdZ0G3wdvH1+LXE5tw=7Cs6Q+HxMcRU0qj5Q@mail.gmail.com","threadId":"59200","inReplyTo":"CAPMMpogFAR6cvcR8T5fx+AoytAJ7TsPpSeOjHNzW4Gmkuq7FLQ@mail.gmail.com","subject":"Re: [PATCH] pull: conflict hint pull.rebase suggestion should offer \"merges\" vs \"true\"","fromName":"Alex Henrie","fromEmail":"alexhenrie24@gmail.com","sentAt":"2023-02-17T03:15:05Z","receivedAt":"2023-02-17T03:15:20Z","isPatch":true,"sender":{"key":"alexhenrie24@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5951993?v=4"},"body":"On Thu, Feb 16, 2023 at 5:31 AM Tao Klerks wrote:\n>\n> If there's an appetite for it, I would love to contribute to a\n> multi-year adventure to change git's behavior, little by little, until\n> the behavior of \"rebase=merges\" is the default, and the old behavior\n> becomes a different option like\n> \"rebase=copy-merged-commits-to-flatten\"\n\nI know you had a lot to say in your last email, but I'd like to focus\non this point. I would be OK with the proposed patch if it were part\nof a larger effort to make --rebase-merges the default behavior of\n`git rebase`. That seems like an achievable goal, and I don't think it\nwould take multiple years, maybe one year at the most. The process\nwould look something like this:\n\n1. Add a --no-rebase-merges option to `git rebase`.\n\n2. Add a rebase.merges config option.\n\n3. Add a warning to `git rebase` that appears if rebase.merges is\nunset and neither --rebase-merges nor --no-rebase-merges is given. The\nwarning would advise the user that the default behavior of `git\nrebase` will change in a future release and suggest setting\nrebase.merges=no-rebase-cousins to get the new behavior now.\n\n4. Change the `git pull` advice to recommend --rebase=merges and\npull.rebase=merges.\n\n5. Wait a couple of releases.\n\n6. Change the default behavior of `git rebase` to `git rebase\n--rebase-merges` and the default behavior of `git pull --rebase` to\n`git pull --rebase=merges`. At the same time, remove the warning from\n`git rebase`. The old `git pull` behavior would still be available as\n`git pull --rebase=true`.\n\n7. Change the `git pull` advice to recommend the short and simple\n--rebase option again (leaving the recommendation of\npull.rebase=merges for the config option).\n\nDoes that sound reasonable? I think I could lend a hand with steps 1-3.\n\n-Alex\n"},{"id":"472253","messageId":"CAPMMpoj0Ts=c=Wq1eghjJ75HVyy5ZyKjL3o9=AB8SDb5Wf99mw@mail.gmail.com","threadId":"59200","inReplyTo":"CAMMLpeTQ1RpsvwRdZ0G3wdvH1+LXE5tw=7Cs6Q+HxMcRU0qj5Q@mail.gmail.com","subject":"Re: [PATCH] pull: conflict hint pull.rebase suggestion should offer \"merges\" vs \"true\"","fromName":"Tao Klerks","fromEmail":"tao@klerks.biz","sentAt":"2023-02-17T11:15:19Z","receivedAt":"2023-02-17T11:15:57Z","isPatch":true,"sender":{"key":"tao@klerks.biz","avatar":"https://avatars.githubusercontent.com/u/531704?v=4"},"body":"On Fri, Feb 17, 2023 at 4:15 AM Alex Henrie wrote:\n>\n> I would be OK with the proposed patch if it were part\n> of a larger effort to make --rebase-merges the default behavior of\n> `git rebase`.\n\nHeh, what would it take to convince you there is such an effort? :) -\nsparse and minor as my contributions are, I certainly believe that is\na \"natural\" effort that I will do what I can to support.\n\n> That seems like an achievable goal, and I don't think it\n> would take multiple years, maybe one year at the most.\n\nMy estimate is based on the observation that there are still, several\nyears after --rebase-merges was introduced, git GUIs that don't handle\nit right - eg Jetbrains IDEA:\nhttps://youtrack.jetbrains.com/issue/IDEA-232160/Rebase-merges-is-not-properly-supported\n\nThis kind of functionality change should be slow, not because it's a\nhuge amount of work, but more because it takes time for the entire\necosystem to adapt. Git releases basically-monthly, but many of the\nsystems that users use git with release far less often; similarly,\nit's helpful to users who use a mix of current and older systems (I'm\nlooking at you, CentOS 7) for the introduction and recommendation of a\nbehavior change to come *long* before its defaulting.\n\n> The process\n> would look something like this:\n>\n> 1. Add a --no-rebase-merges option to `git rebase`.\n>\n> 2. Add a rebase.merges config option.\n\nYes and yes! I alluded to this in\nhttps://lore.kernel.org/git/CAPMMpoj6E-85a59EaHD2aR_oKA=_u78qRV+wp8mqXkR39KctmA@mail.gmail.com/\nbut didn't feel I'd likely to make a solid change along these lines.\n\n>\n> 3. Add a warning to `git rebase` that appears if rebase.merges is\n> unset and neither --rebase-merges nor --no-rebase-merges is given. The\n> warning would advise the user that the default behavior of `git\n> rebase` will change in a future release and suggest setting\n> rebase.merges=no-rebase-cousins to get the new behavior now.\n>\n\nMakes sense to me!\n\n> 4. Change the `git pull` advice to recommend --rebase=merges and\n> pull.rebase=merges.\n>\n\nI'm not sure why this would be step 4 - I would (and did try to) make\nit step 1 :)\n\n> 5. Wait a couple of releases.\n>\n\nAs I noted above, I believe it should be far more than a couple.\n\n> 6. Change the default behavior of `git rebase` to `git rebase\n> --rebase-merges` and the default behavior of `git pull --rebase` to\n> `git pull --rebase=merges`. At the same time, remove the warning from\n> `git rebase`. The old `git pull` behavior would still be available as\n> `git pull --rebase=true`.\n>\n\nMakes sense to me!\n\n> 7. Change the `git pull` advice to recommend the short and simple\n> --rebase option again (leaving the recommendation of\n> pull.rebase=merges for the config option).\n>\n> Does that sound reasonable? I think I could lend a hand with steps 1-3.\n>\n\nI'm sold, except insofar as I think the right approach is to move step\n4 to be the first :)\n"},{"id":"472258","messageId":"xmqqilg0mbs8.fsf@gitster.g","threadId":"59200","inReplyTo":"CAMMLpeTQ1RpsvwRdZ0G3wdvH1+LXE5tw=7Cs6Q+HxMcRU0qj5Q@mail.gmail.com","subject":"Re: [PATCH] pull: conflict hint pull.rebase suggestion should offer \"merges\" vs \"true\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-02-17T17:39:35Z","receivedAt":"2023-02-17T17:39:45Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Alex Henrie writes:\n\n> 1. Add a --no-rebase-merges option to `git rebase`.\n>\n> 2. Add a rebase.merges config option.\n>\n> 3. Add a warning to `git rebase` that appears if rebase.merges is\n> unset and neither --rebase-merges nor --no-rebase-merges is given. The\n> warning would advise the user that the default behavior of `git\n> rebase` will change in a future release and suggest setting\n> rebase.merges=no-rebase-cousins to get the new behavior now.\n>\n> 4. Change the `git pull` advice to recommend --rebase=merges and\n> pull.rebase=merges.\n>\n> 5. Wait a couple of releases.\n\nThe above sounds like a standard \"flip the default\" dance executed\nin the usual order. I am not sure about the remainder but that is\nnot because I find anything wrong in it, but because I haven't\nthought things through that far into the future ;-).\n"},{"id":"472259","messageId":"CAMMLpeSGzuVEwvwP8ySUyo0FBcanUjm2psU_+adh_dHTM8vP9Q@mail.gmail.com","threadId":"59200","inReplyTo":"CAPMMpoj0Ts=c=Wq1eghjJ75HVyy5ZyKjL3o9=AB8SDb5Wf99mw@mail.gmail.com","subject":"Re: [PATCH] pull: conflict hint pull.rebase suggestion should offer \"merges\" vs \"true\"","fromName":"Alex Henrie","fromEmail":"alexhenrie24@gmail.com","sentAt":"2023-02-17T18:56:16Z","receivedAt":"2023-02-17T18:56:32Z","isPatch":true,"sender":{"key":"alexhenrie24@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5951993?v=4"},"body":"On Fri, Feb 17, 2023 at 4:15 AM Tao Klerks wrote:\n>\n> On Fri, Feb 17, 2023 at 4:15 AM Alex Henrie wrote:\n> >\n> > I would be OK with the proposed patch if it were part\n> > of a larger effort to make --rebase-merges the default behavior of\n> > `git rebase`.\n>\n> Heh, what would it take to convince you there is such an effort? :)\n\nDoing steps 1-3 :)\n\n> > 4. Change the `git pull` advice to recommend --rebase=merges and\n> > pull.rebase=merges.\n>\n> I'm not sure why this would be step 4 - I would (and did try to) make\n> it step 1 :)\n\nThe unintuitive syntax --rebase=merges makes a little more sense if\nthere is a warning in `git rebase` about it being a temporary\nnecessity to support a planned behavior change, and we're explicitly\ncommitting to not expect users to use that syntax forever. It might be\na good idea to add a similar note to the `git pull` warning too.\n\n-Alex\n"},{"id":"472292","messageId":"CABPp-BFxGYQ_JTC5c4_S_gOK3GxWKuZ=KfvycpkBjPGyKzCJ+g@mail.gmail.com","threadId":"59200","inReplyTo":"CAMMLpeTQ1RpsvwRdZ0G3wdvH1+LXE5tw=7Cs6Q+HxMcRU0qj5Q@mail.gmail.com","subject":"Re: [PATCH] pull: conflict hint pull.rebase suggestion should offer \"merges\" vs \"true\"","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2023-02-18T03:17:00Z","receivedAt":"2023-02-18T03:17:33Z","isPatch":true,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Thu, Feb 16, 2023 at 8:02 PM Alex Henrie wrote:\n>\n> On Thu, Feb 16, 2023 at 5:31 AM Tao Klerks wrote:\n> >\n> > If there's an appetite for it, I would love to contribute to a\n> > multi-year adventure to change git's behavior, little by little, until\n> > the behavior of \"rebase=merges\" is the default, and the old behavior\n> > becomes a different option like\n> > \"rebase=copy-merged-commits-to-flatten\"\n>\n> I know you had a lot to say in your last email, but I'd like to focus\n> on this point. I would be OK with the proposed patch if it were part\n> of a larger effort to make --rebase-merges the default behavior of\n> `git rebase`. That seems like an achievable goal, and I don't think it\n> would take multiple years, maybe one year at the most. The process\n> would look something like this:\n>\n> 1. Add a --no-rebase-merges option to `git rebase`.\n>\n> 2. Add a rebase.merges config option.\n>\n> 3. Add a warning to `git rebase` that appears if rebase.merges is\n> unset and neither --rebase-merges nor --no-rebase-merges is given. The\n> warning would advise the user that the default behavior of `git\n> rebase` will change in a future release and suggest setting\n> rebase.merges=no-rebase-cousins to get the new behavior now.\n>\n> 4. Change the `git pull` advice to recommend --rebase=merges and\n> pull.rebase=merges.\n>\n> 5. Wait a couple of releases.\n>\n> 6. Change the default behavior of `git rebase` to `git rebase\n> --rebase-merges` and the default behavior of `git pull --rebase` to\n> `git pull --rebase=merges`. At the same time, remove the warning from\n> `git rebase`. The old `git pull` behavior would still be available as\n> `git pull --rebase=true`.\n>\n> 7. Change the `git pull` advice to recommend the short and simple\n> --rebase option again (leaving the recommendation of\n> pull.rebase=merges for the config option).\n>\n> Does that sound reasonable? I think I could lend a hand with steps 1-3.\n\nOne concern I have is that \"--rebase-merges\" itself has negative user\nsurprises in store. In particular, \"--rebase-merges\", despite its\nname, does not rebase merges. It uses the existing author & commit\nmessage info, but otherwise just discards the existing merge and\ncreates a new one. Any information it contained about fixing\nconflicts, or making adjustments to make the two branches work\ntogether, is summarily and silently discarded.\n\nMy personal opinion would be adding such a capability should be step\n2.5 in your list, though I suspect that would make Tao unhappy (it's a\nnon-trivial amount of work, unlike the other steps in your list).\n"},{"id":"472301","messageId":"c3ef69e0-c37a-01fe-a40a-c2940e329793@dunelm.org.uk","threadId":"59200","inReplyTo":"CABPp-BFxGYQ_JTC5c4_S_gOK3GxWKuZ=KfvycpkBjPGyKzCJ+g@mail.gmail.com","subject":"Re: [PATCH] pull: conflict hint pull.rebase suggestion should offer \"merges\" vs \"true\"","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2023-02-18T16:39:40Z","receivedAt":"2023-02-18T16:39:48Z","isPatch":true,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"On 18/02/2023 03:17, Elijah Newren wrote:\n> On Thu, Feb 16, 2023 at 8:02 PM Alex Henrie wrote:\n>>\n>> On Thu, Feb 16, 2023 at 5:31 AM Tao Klerks wrote:\n>>>\n>>> If there's an appetite for it, I would love to contribute to a\n>>> multi-year adventure to change git's behavior, little by little, until\n>>> the behavior of \"rebase=merges\" is the default, and the old behavior\n>>> becomes a different option like\n>>> \"rebase=copy-merged-commits-to-flatten\"\n>>\n>> I know you had a lot to say in your last email, but I'd like to focus\n>> on this point. I would be OK with the proposed patch if it were part\n>> of a larger effort to make --rebase-merges the default behavior of\n>> `git rebase`. That seems like an achievable goal, and I don't think it\n>> would take multiple years, maybe one year at the most. The process\n>> would look something like this:\n>>\n>> 1. Add a --no-rebase-merges option to `git rebase`.\n>>\n>> 2. Add a rebase.merges config option.\n>>\n>> 3. Add a warning to `git rebase` that appears if rebase.merges is\n>> unset and neither --rebase-merges nor --no-rebase-merges is given. The\n>> warning would advise the user that the default behavior of `git\n>> rebase` will change in a future release and suggest setting\n>> rebase.merges=no-rebase-cousins to get the new behavior now.\n>>\n>> 4. Change the `git pull` advice to recommend --rebase=merges and\n>> pull.rebase=merges.\n>>\n>> 5. Wait a couple of releases.\n>>\n>> 6. Change the default behavior of `git rebase` to `git rebase\n>> --rebase-merges` and the default behavior of `git pull --rebase` to\n>> `git pull --rebase=merges`. At the same time, remove the warning from\n>> `git rebase`. The old `git pull` behavior would still be available as\n>> `git pull --rebase=true`.\n>>\n>> 7. Change the `git pull` advice to recommend the short and simple\n>> --rebase option again (leaving the recommendation of\n>> pull.rebase=merges for the config option).\n>>\n>> Does that sound reasonable? I think I could lend a hand with steps 1-3.\n> \n> One concern I have is that \"--rebase-merges\" itself has negative user\n> surprises in store. In particular, \"--rebase-merges\", despite its\n> name, does not rebase merges. It uses the existing author & commit\n> message info, but otherwise just discards the existing merge and\n> creates a new one. Any information it contained about fixing\n> conflicts, or making adjustments to make the two branches work\n> together, is summarily and silently discarded.\n\nThat's a good point. Another potentially surprising behavior is that \nwhen I'm rebasing an integration branch with -rno-rebase-cousins then if \none of the topic branches merged into the integration branch happens to \nshare the same base as the integration branch itself the topic branch \ngets rebased as well. -rno-rebase-cousins is also slower that it needs \nto be because it creates a todo list that contains all the commits on \nthe topic branches merged into the integration branch rather than just \nthe merges. The commits on the topic branches are fast-forwarded rather \nthan rewritten so long as they don't share the same base as the \nintegration branch but it noticeably slower than using a todo list with \njust the merge commands.\n\n> My personal opinion would be adding such a capability should be step\n> 2.5 in your list, though I suspect that would make Tao unhappy (it's a\n> non-trivial amount of work, unlike the other steps in your list).\n\nI've got a couple of patches[1] that cherry-pick the merge if only one \nof the parents has changed. I've never tried upstreaming them as it is \nonly a partial solution to the problem of rebasing merges but that \napproach should work well with \"git pull --rebase=merges\" as only the \nupstream side will have changed (when rebasing my git integration branch \nwith that patch the merges are cherry-picked). They might make a useful \nstarting point if anyone wants to try and improve the rebasing of merges.\n\nBest Wishes\n\nPhillip\n\n[1] https://github.com/phillipwood/git/commits/rebase-cherry-pick-merges\n"},{"id":"472321","messageId":"CAPMMpojCYAwwu6_BE+myFaUy6fLqVSWAyiRWr_dGAmMqqUF12Q@mail.gmail.com","threadId":"59200","inReplyTo":"CABPp-BFxGYQ_JTC5c4_S_gOK3GxWKuZ=KfvycpkBjPGyKzCJ+g@mail.gmail.com","subject":"Re: [PATCH] pull: conflict hint pull.rebase suggestion should offer \"merges\" vs \"true\"","fromName":"Tao Klerks","fromEmail":"tao@klerks.biz","sentAt":"2023-02-20T06:01:14Z","receivedAt":"2023-02-20T06:01:30Z","isPatch":true,"sender":{"key":"tao@klerks.biz","avatar":"https://avatars.githubusercontent.com/u/531704?v=4"},"body":"On Sat, Feb 18, 2023 at 4:17 AM Elijah Newren wrote:\n>\n> On Thu, Feb 16, 2023 at 8:02 PM Alex Henrie wrote:\n> >\n> > On Thu, Feb 16, 2023 at 5:31 AM Tao Klerks wrote:\n> > >\n> > > If there's an appetite for it, I would love to contribute to a\n> > > multi-year adventure to change git's behavior, little by little, until\n> > > the behavior of \"rebase=merges\" is the default, and the old behavior\n> > > becomes a different option like\n> > > \"rebase=copy-merged-commits-to-flatten\"\n> >\n> > I know you had a lot to say in your last email, but I'd like to focus\n> > on this point. I would be OK with the proposed patch if it were part\n> > of a larger effort to make --rebase-merges the default behavior of\n> > `git rebase`. That seems like an achievable goal, and I don't think it\n> > would take multiple years, maybe one year at the most. The process\n> > would look something like this:\n> >\n\n> >\n> > Does that sound reasonable? I think I could lend a hand with steps 1-3.\n>\n> One concern I have is that \"--rebase-merges\" itself has negative user\n> surprises in store. In particular, \"--rebase-merges\", despite its\n> name, does not rebase merges. It uses the existing author & commit\n> message info, but otherwise just discards the existing merge and\n> creates a new one. Any information it contained about fixing\n> conflicts, or making adjustments to make the two branches work\n> together, is summarily and silently discarded.\n>\n> My personal opinion would be adding such a capability should be step\n> 2.5 in your list, though I suspect that would make Tao unhappy (it's a\n> non-trivial amount of work, unlike the other steps in your list).\n\nI apologize for my ignorance here, but I'm not sure how this \"does not\nrebase merges\" concern overlaps with the \"pull.rebase\" context I'm\nmost specifically concerned about.\n\nI would have assumed that when merge commits are \"dropped\", as results\nfrom the current \"pull.rebase=true\" option in the pull conflict\nadvice, any merge resolution information is *also* dropped - so there\nis no loss to the user here in advising the use of\n\"pull.rebase=merges\" instead.\n\nIs your concern about the \"pull.rebase=merges\" advice change, or more\nabout the broader \"let's encourage users to more explicitly choose\nbetween traditional merge-dropping rebase and rebase-merges\" change\nAlex is advocating for as a precondition to \"my\" change :) ?\n"},{"id":"472324","messageId":"CAPMMpogi_QoGKD824JW+85v_Sgaf5d3TAd_P55YyT5NF6AUJ=w@mail.gmail.com","threadId":"59200","inReplyTo":"c3ef69e0-c37a-01fe-a40a-c2940e329793@dunelm.org.uk","subject":"Re: [PATCH] pull: conflict hint pull.rebase suggestion should offer \"merges\" vs \"true\"","fromName":"Tao Klerks","fromEmail":"tao@klerks.biz","sentAt":"2023-02-20T08:03:29Z","receivedAt":"2023-02-20T08:03:45Z","isPatch":true,"sender":{"key":"tao@klerks.biz","avatar":"https://avatars.githubusercontent.com/u/531704?v=4"},"body":"On Sat, Feb 18, 2023 at 5:39 PM Phillip Wood wrote:\n>\n> On 18/02/2023 03:17, Elijah Newren wrote:\n> >\n> > One concern I have is that \"--rebase-merges\" itself has negative user\n> > surprises in store. In particular, \"--rebase-merges\", despite its\n> > name, does not rebase merges. It uses the existing author & commit\n> > message info, but otherwise just discards the existing merge and\n> > creates a new one. Any information it contained about fixing\n> > conflicts, or making adjustments to make the two branches work\n> > together, is summarily and silently discarded.\n>\n> That's a good point. Another potentially surprising behavior is that\n> when I'm rebasing an integration branch with -rno-rebase-cousins then if\n> one of the topic branches merged into the integration branch happens to\n> share the same base as the integration branch itself the topic branch\n> gets rebased as well.\n\nI've been trying to understand how this behavior is (potentially)\nsurprising - I imagine it's been discussed elsewhere but I'm having a\nhard time understanding, sorry.\n\nThe situation you described is a boundary condition between two others, right?\n* The topic branch could be branched from the integration branch\n(potentially *after* some other change were made to the integration\nbranch, but not in this case) - in which case rebasing is what you\nwould expect\n* The topic branch could be branched from the main branch (potentially\n*before* the integration branch branched, but not in this case) - in\nwhich case not rebasing is what you would expect.\n\nIf topic branched from main (at around the same time as integration),\nit might be surprising that it rebases; if it branched from\nintegration (before that had any changes), then it is expected.\n\n> -rno-rebase-cousins is also slower that it needs\n> to be because it creates a todo list that contains all the commits on\n> the topic branches merged into the integration branch rather than just\n> the merges. The commits on the topic branches are fast-forwarded rather\n> than rewritten so long as they don't share the same base as the\n> integration branch but it noticeably slower than using a todo list with\n> just the merge commands.\n\nThis seems improvable, but no worse than a plain legacy rebase (as\nAlex's new patch would have it, \"rebase-merges=drop\"), right? Insofar\nas we're discussing why it might make sense to avoid promoting this\nover a plain rebase, I don't understand the concern.\n\n\n>\n> > My personal opinion would be adding such a capability should be step\n> > 2.5 in your list, though I suspect that would make Tao unhappy (it's a\n> > non-trivial amount of work, unlike the other steps in your list).\n>\n> I've got a couple of patches[1] that cherry-pick the merge if only one\n> of the parents has changed. I've never tried upstreaming them as it is\n> only a partial solution to the problem of rebasing merges but that\n> approach should work well with \"git pull --rebase=merges\" as only the\n> upstream side will have changed (when rebasing my git integration branch\n> with that patch the merges are cherry-picked). They might make a useful\n> starting point if anyone wants to try and improve the rebasing of merges.\n>\n\nThis is awesome!\n\nIt feels like the first step towards the general strategy that was (I\nbelieve) best described by Buga at\nhttps://public-inbox.org/git/a0cc88d2-bfed-ce7b-1b3f-3c447d2b32da@gmail.com/\n!\n\n(unless I'm missing something, the result of this is exactly the same\nas the result of that strategy, in these \"simple\" cases where it kicks\nin)\n\nThe one concern I have with this is that, *if I understand correctly*,\nit sometimes throws away the existing merge information, and sometimes\ndoesn't, and there's no easy way to know which it is at runtime. Would\nadding a warning on stderr when a both-parents merge is encountered\n(and any merge resolutions or related changes are still discarded) be\nenough to make this shippable?\n\nAre there *any* circumstances where the new cherry-picking behavior\nintroduced here wouldn't be the right thing to have happen?\n"},{"id":"472341","messageId":"55818a65-046d-4f96-312b-1b5cae6e210f@dunelm.org.uk","threadId":"59200","inReplyTo":"CAPMMpogi_QoGKD824JW+85v_Sgaf5d3TAd_P55YyT5NF6AUJ=w@mail.gmail.com","subject":"Re: [PATCH] pull: conflict hint pull.rebase suggestion should offer \"merges\" vs \"true\"","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2023-02-20T16:45:44Z","receivedAt":"2023-02-20T16:47:20Z","isPatch":true,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"Hi Tao\n\nOn 20/02/2023 08:03, Tao Klerks wrote:\n> On Sat, Feb 18, 2023 at 5:39 PM Phillip Wood wrote:\n>>\n>> On 18/02/2023 03:17, Elijah Newren wrote:\n>>>\n>>> One concern I have is that \"--rebase-merges\" itself has negative user\n>>> surprises in store. In particular, \"--rebase-merges\", despite its\n>>> name, does not rebase merges. It uses the existing author & commit\n>>> message info, but otherwise just discards the existing merge and\n>>> creates a new one. Any information it contained about fixing\n>>> conflicts, or making adjustments to make the two branches work\n>>> together, is summarily and silently discarded.\n>>\n>> That's a good point. Another potentially surprising behavior is that\n>> when I'm rebasing an integration branch with -rno-rebase-cousins then if\n>> one of the topic branches merged into the integration branch happens to\n>> share the same base as the integration branch itself the topic branch\n>> gets rebased as well.\n> \n> I've been trying to understand how this behavior is (potentially)\n> surprising - I imagine it's been discussed elsewhere but I'm having a\n> hard time understanding, sorry.\n> \n> The situation you described is a boundary condition between two others, right?\n> * The topic branch could be branched from the integration branch\n> (potentially *after* some other change were made to the integration\n> branch, but not in this case) - in which case rebasing is what you\n> would expect\n> * The topic branch could be branched from the main branch (potentially\n> *before* the integration branch branched, but not in this case) - in\n> which case not rebasing is what you would expect.\n> \n> If topic branched from main (at around the same time as integration),\n> it might be surprising that it rebases;\n\nYes that's what I was referring to, on the one hand it isn't surprising \nat all because both the topic and integration branch have the same base \nbut on the other hand using no-rebase-cousins is supposed to stop the \ntopic branches being rebased.\n\n> if it branched from\n> integration (before that had any changes), then it is expected.\n\nYes\n\n>> -rno-rebase-cousins is also slower that it needs\n>> to be because it creates a todo list that contains all the commits on\n>> the topic branches merged into the integration branch rather than just\n>> the merges. The commits on the topic branches are fast-forwarded rather\n>> than rewritten so long as they don't share the same base as the\n>> integration branch but it noticeably slower than using a todo list with\n>> just the merge commands.\n> \n> This seems improvable, but no worse than a plain legacy rebase (as\n> Alex's new patch would have it, \"rebase-merges=drop\"), right? Insofar\n> as we're discussing why it might make sense to avoid promoting this\n> over a plain rebase, I don't understand the concern.\n\nMy concern is to have a good understanding of the issues around \n--rebase-merges before we start promoting it over a plain rebase. It is \nnot a reason not to make the change but it does show --rebase-merges \nwould benefit from some additional polish.\n\n>>> My personal opinion would be adding such a capability should be step\n>>> 2.5 in your list, though I suspect that would make Tao unhappy (it's a\n>>> non-trivial amount of work, unlike the other steps in your list).\n>>\n>> I've got a couple of patches[1] that cherry-pick the merge if only one\n>> of the parents has changed. I've never tried upstreaming them as it is\n>> only a partial solution to the problem of rebasing merges but that\n>> approach should work well with \"git pull --rebase=merges\" as only the\n>> upstream side will have changed (when rebasing my git integration branch\n>> with that patch the merges are cherry-picked). They might make a useful\n>> starting point if anyone wants to try and improve the rebasing of merges.\n>>\n> \n> This is awesome!\n> \n> It feels like the first step towards the general strategy that was (I\n> believe) best described by Buga at\n> https://public-inbox.org/git/a0cc88d2-bfed-ce7b-1b3f-3c447d2b32da@gmail.com/\n> !\n> \n> (unless I'm missing something, the result of this is exactly the same\n> as the result of that strategy, in these \"simple\" cases where it kicks\n> in)\n\nYes\n\n> The one concern I have with this is that, *if I understand correctly*,\n> it sometimes throws away the existing merge information, and sometimes\n> doesn't, and there's no easy way to know which it is at runtime.\n\nRight, there are two ways the existing merge can be thrown away.\n\n (i) The existing merge has conflicts when being cherry picked\n and so we redo the merge (that is a choice, we could present\n the user with the conflicts from the cherry-pick). It is\n possible that the merge succeeds where the cherry-pick failed\n but most of the time we'd stop because if the cherry-pick has\n conflicts the merge will probably have conflicts as well.\n\n(ii) More than one parent has changed and so we redo the merge\n\n> Would\n> adding a warning on stderr when a both-parents merge is encountered\n> (and any merge resolutions or related changes are still discarded) be\n> enough to make this shippable?\n\nI'm not sure. It works well enough for what I use it for (which is \nessentially \"git pull --rebase\") but sometimes cherry-picking and \nsometimes remerging does make it more complicated for users. If we \nprinted a warning what is the user going to do? An experienced user can \nuse the reflog to get back to the original state and redo the rebase \nwith some break statements added in to let them fix up the merges. A \nless experienced user is going to think git lost their work.\n\n> Are there *any* circumstances where the new cherry-picking behavior\n> introduced here wouldn't be the right thing to have happen?\n\nNot that I can think of\n\nBest Wishes\n\nPhillip\n"},{"id":"472342","messageId":"CABPp-BEAqP7maTVw82Qr8mn-sxPzXmHnE_mTKf2pg6hVYAJSUw@mail.gmail.com","threadId":"59200","inReplyTo":"c3ef69e0-c37a-01fe-a40a-c2940e329793@dunelm.org.uk","subject":"Re: [PATCH] pull: conflict hint pull.rebase suggestion should offer \"merges\" vs \"true\"","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2023-02-20T16:46:32Z","receivedAt":"2023-02-20T16:47:43Z","isPatch":true,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"Hi Phillip,\n\nOn Sat, Feb 18, 2023 at 8:39 AM Phillip Wood wrote:\n>\n> On 18/02/2023 03:17, Elijah Newren wrote:\n> >\n> > One concern I have is that \"--rebase-merges\" itself has negative user\n> > surprises in store. In particular, \"--rebase-merges\", despite its\n> > name, does not rebase merges. It uses the existing author & commit\n> > message info, but otherwise just discards the existing merge and\n> > creates a new one. Any information it contained about fixing\n> > conflicts, or making adjustments to make the two branches work\n> > together, is summarily and silently discarded.\n>\n> That's a good point. Another potentially surprising behavior is that\n> when I'm rebasing an integration branch with -rno-rebase-cousins then if\n> one of the topic branches merged into the integration branch happens to\n> share the same base as the integration branch itself the topic branch\n> gets rebased as well. -rno-rebase-cousins is also slower that it needs\n> to be because it creates a todo list that contains all the commits on\n> the topic branches merged into the integration branch rather than just\n> the merges. The commits on the topic branches are fast-forwarded rather\n> than rewritten so long as they don't share the same base as the\n> integration branch but it noticeably slower than using a todo list with\n> just the merge commands.\n\nYeah, modifying rebase to accept a general range expression (instead\nof assuming upstream..HEAD) would really help. Then, to get just the\nparts you are interested in, you could use a range with extra commit\nexclusions and additional qualifiers like --ancestry-path= and\n--first-parent. In fact, you could also list multiple branches (none\nof which necessarily fully contains any of the others) to replay\nmultiple branches at a time. (See [2] for where I discuss this\nmore, though focusing on the --ancestry-path= part of it.).\n\nBut, it'd also fundamentally break existing workflows, so it might\nhave to be a new command, perhaps `git replay`. However, there's\nmultiple other improvements needed in rebase (such as not wasting time\nupdating the working tree or index or reflog for every commit, or\nwasting time writing N control files when we could move to 1 control\nfile, and allowing working on branches that aren't checked out) that I\nthink would likely also break compatibility, so maybe another command\nis a good idea anyway[3].\n\n[2] https://lore.kernel.org/git/CABPp-BHmj+QCBFDrH77iNfEU41V=UDu7nhBYkAbCsbXhshJzzw@mail.gmail.com/\n[3] https://github.com/newren/git/blob/e84f5f3585fd770ed21f398d2ae5f96e90a51b1e/replay-design-notes.txt\n\n> > My personal opinion would be adding such a capability should be step\n> > 2.5 in your list, though I suspect that would make Tao unhappy (it's a\n> > non-trivial amount of work, unlike the other steps in your list).\n>\n> I've got a couple of patches[1] that cherry-pick the merge if only one\n> of the parents has changed. I've never tried upstreaming them as it is\n> only a partial solution to the problem of rebasing merges but that\n> approach should work well with \"git pull --rebase=merges\" as only the\n> upstream side will have changed (when rebasing my git integration branch\n> with that patch the merges are cherry-picked). They might make a useful\n> starting point if anyone wants to try and improve the rebasing of merges.\n\nI've actually put quite a bit of time into this problem. I have\noutlined what I think is a full solution to the rebasing of merges\nproblem space at [4], which expands on my earlier discussion with\nJohannes on-list over at [5] (which in turn was a follow-up to\nprevious discussions that you, Johannes, and several others had years\nago). If you're interested and have any thoughts on my plans for this\nproblem space, I'd love to hear it. You tend to have very strong\ninsights on everything xdiff, sequencer, and rebasing related. My\n\"replay\" branch contains a partial implementation, but it's not really\nusable for anything rebase-merges-related yet, so you'd mostly have to\ngo with my writeups.\n\nA warning, though, that I won't be able to respond to feedback on this\ntopic very soon. I will definitely get back to working on it, but\nit's been much more challenging with more limited git time these days.\nUnfortunately, the current economic environment reduces the number of\nways possible to extend the amount of time available for working on\nGit, but one way or another I'll eventually get back to this problem\nand implement my ideas, unless someone beats me to it.\n\n[4] https://github.com/newren/git/blob/e84f5f3585fd770ed21f398d2ae5f96e90a51b1e/replay-design-notes.txt#L264-L341\n[5] https://lore.kernel.org/git/CABPp-BHWVO5VRhr1-Ou60F1wjKzJZ1e_dC01Mmzs+qB9kGayww@mail.gmail.com/\n"},{"id":"472344","messageId":"CABPp-BFhvX6eg04+qTk7P64NfmUKnCTV7o1ufp447z6-XdUcJw@mail.gmail.com","threadId":"59200","inReplyTo":"CAPMMpogi_QoGKD824JW+85v_Sgaf5d3TAd_P55YyT5NF6AUJ=w@mail.gmail.com","subject":"Re: [PATCH] pull: conflict hint pull.rebase suggestion should offer \"merges\" vs \"true\"","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2023-02-20T16:56:27Z","receivedAt":"2023-02-20T16:56:44Z","isPatch":true,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Mon, Feb 20, 2023 at 12:03 AM Tao Klerks wrote:\n>\n> On Sat, Feb 18, 2023 at 5:39 PM Phillip Wood wrote:\n> >\n> > On 18/02/2023 03:17, Elijah Newren wrote:\n> > >\n[...]\n> > > My personal opinion would be adding such a capability should be step\n> > > 2.5 in your list, though I suspect that would make Tao unhappy (it's a\n> > > non-trivial amount of work, unlike the other steps in your list).\n> >\n> > I've got a couple of patches[1] that cherry-pick the merge if only one\n> > of the parents has changed. I've never tried upstreaming them as it is\n> > only a partial solution to the problem of rebasing merges but that\n> > approach should work well with \"git pull --rebase=merges\" as only the\n> > upstream side will have changed (when rebasing my git integration branch\n> > with that patch the merges are cherry-picked). They might make a useful\n> > starting point if anyone wants to try and improve the rebasing of merges.\n> >\n>\n> This is awesome!\n>\n> It feels like the first step towards the general strategy that was (I\n> believe) best described by Buga at\n> https://public-inbox.org/git/a0cc88d2-bfed-ce7b-1b3f-3c447d2b32da@gmail.com/\n> !\n\nThe strategies described by Buga and others in that mega-thread were\nsuboptimal solutions, in my opinion. Johannes went and implemented\nsome and found them wanting; see the thread over at\nhttps://lore.kernel.org/git/nycvar.QRO.7.76.6.1804130002090.65@ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz/.\nThere were follow-ups with an improved strategy in the thread over at\nhttps://lore.kernel.org/git/CABPp-BHWVO5VRhr1-Ou60F1wjKzJZ1e_dC01Mmzs+qB9kGayww@mail.gmail.com/\n(Note that this route has also independently been discovered and\nimplemented in jj and found to work well, though it does handle\nconflicts much differently). And I've since improved the strategy\nfurther at https://github.com/newren/git/blob/e84f5f3585fd770ed21f398d2ae5f96e90a51b1e/replay-design-notes.txt#L264-L341.\nHowever, note that this isn't a case of merely performing the proper\nseries of merges, it needs some specialized logic and some new\ncapabilities at the xdiff level.\n"},{"id":"472347","messageId":"CABPp-BEtXf9ja7Ec1fZ=BZwFDa+50zSAhtm3nN_=k+Nc2c=RXw@mail.gmail.com","threadId":"59200","inReplyTo":"CAPMMpojCYAwwu6_BE+myFaUy6fLqVSWAyiRWr_dGAmMqqUF12Q@mail.gmail.com","subject":"Re: [PATCH] pull: conflict hint pull.rebase suggestion should offer \"merges\" vs \"true\"","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2023-02-20T17:20:47Z","receivedAt":"2023-02-20T17:21:06Z","isPatch":true,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Sun, Feb 19, 2023 at 10:01 PM Tao Klerks wrote:\n>\n> On Sat, Feb 18, 2023 at 4:17 AM Elijah Newren wrote:\n> >\n> > On Thu, Feb 16, 2023 at 8:02 PM Alex Henrie wrote:\n> > >\n> > > On Thu, Feb 16, 2023 at 5:31 AM Tao Klerks wrote:\n> > > >\n> > > > If there's an appetite for it, I would love to contribute to a\n> > > > multi-year adventure to change git's behavior, little by little, until\n> > > > the behavior of \"rebase=merges\" is the default, and the old behavior\n> > > > becomes a different option like\n> > > > \"rebase=copy-merged-commits-to-flatten\"\n> > >\n> > > I know you had a lot to say in your last email, but I'd like to focus\n> > > on this point. I would be OK with the proposed patch if it were part\n> > > of a larger effort to make --rebase-merges the default behavior of\n> > > `git rebase`. That seems like an achievable goal, and I don't think it\n> > > would take multiple years, maybe one year at the most. The process\n> > > would look something like this:\n> > >\n> \n> > >\n> > > Does that sound reasonable? I think I could lend a hand with steps 1-3.\n> >\n> > One concern I have is that \"--rebase-merges\" itself has negative user\n> > surprises in store. In particular, \"--rebase-merges\", despite its\n> > name, does not rebase merges. It uses the existing author & commit\n> > message info, but otherwise just discards the existing merge and\n> > creates a new one. Any information it contained about fixing\n> > conflicts, or making adjustments to make the two branches work\n> > together, is summarily and silently discarded.\n> >\n> > My personal opinion would be adding such a capability should be step\n> > 2.5 in your list, though I suspect that would make Tao unhappy (it's a\n> > non-trivial amount of work, unlike the other steps in your list).\n>\n> I apologize for my ignorance here, but I'm not sure how this \"does not\n> rebase merges\" concern overlaps with the \"pull.rebase\" context I'm\n> most specifically concerned about.\n>\n> I would have assumed that when merge commits are \"dropped\", as results\n> from the current \"pull.rebase=true\" option in the pull conflict\n> advice, any merge resolution information is *also* dropped - so there\n> is no loss to the user here in advising the use of\n> \"pull.rebase=merges\" instead.\n>\n> Is your concern about the \"pull.rebase=merges\" advice change, or more\n> about the broader \"let's encourage users to more explicitly choose\n> between traditional merge-dropping rebase and rebase-merges\" change\n> Alex is advocating for as a precondition to \"my\" change :) ?\n\nWhen we teach new folks about git, and get to rebasing, there is a\nsimple and easy rule to tell users: don't mix merges and rebases.\n(There's a minor exception there in that merges with the upstream\nbranch are fine and rebasing can let you get rid of those otherwise\nugly-and-frequent back-merges that users sometimes make.)\n\nObviously, your users are ignoring that advice, and feeling pain. To\nbe fair, the \"RECOVERING FROM UPSTREAM REBASE\" section of the rebase\nmanual isn't that prominent, and perhaps your users didn't have more\nseasoned developers sharing this don't-mix-merges-and-rebases advice\nwith them. (It seemed to me to be shared pretty widely and commonly,\nbut perhaps we are relying on education from others too much and\neducation is never uniform if not coming from the tool itself.) I\nunderstand you want to make it easier for users to avoid accidentally\ngetting into this state. That's a valid concern and desire. I think\nwe should improve the situation.\n\nHowever, on what timetable and at what cost to others?\n\nYou're advocating we start advertising an alternate option, one which\nhas some caveats and gotchas that are not going to be so easy to\nexplain to users -- neither to new users, nor to folks who have been\nusing Git for years. We could just bite the bullet and start\nexplaining, but these caveats and gotchas are completely incidental to\nthe implementation, and are in no-wise fundamental to the desired\noperation. I believe that switching to this new option is going to\ngenerate an awful lot of questions and surprises by users. It seems\nto me to be a really sad state of affairs to be recommending an option\nwith known defects when (IMO) the solution is known. Can't we fix it\nfirst, then recommend it?\n\nGranted, this is a trade-off. You have users experiencing real pain.\nYou want a solution now. I want to not recommend features with known\nimplementation shortcomings and known solutions, until those solutions\nare implemented, and I know that will take a while. What to do here\nis a judgement call, and I was merely giving my opinion on the call to\nmake. Other folks on the list might see things differently than I do.\n"},{"id":"472350","messageId":"CAMMLpeSZs8DqrN6_F9-eg7fcbjV-O5+3V+hUsOhyd0x10xsCaQ@mail.gmail.com","threadId":"59200","inReplyTo":"CABPp-BEtXf9ja7Ec1fZ=BZwFDa+50zSAhtm3nN_=k+Nc2c=RXw@mail.gmail.com","subject":"Re: [PATCH] pull: conflict hint pull.rebase suggestion should offer \"merges\" vs \"true\"","fromName":"Alex Henrie","fromEmail":"alexhenrie24@gmail.com","sentAt":"2023-02-20T18:33:01Z","receivedAt":"2023-02-20T18:33:17Z","isPatch":true,"sender":{"key":"alexhenrie24@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5951993?v=4"},"body":"On Sun, Feb 5, 2023 at 9:41 AM Tao Klerks via GitGitGadget\n wrote:\n>\n> From: Tao Klerks \n>\n> Unfortunately, this rebase configuration can easily lead to non-expert users\n> accidentally rebasing not their own commits, instead others' commits, if the\n> new commits they have locally before the \"pull\" include a merge of another\n> branch, eg \"main\".\n\nOn Mon, Feb 20, 2023 at 10:21 AM Elijah Newren wrote:\n>\n> When we teach new folks about git, and get to rebasing, there is a\n> simple and easy rule to tell users: don't mix merges and rebases.\n> (There's a minor exception there in that merges with the upstream\n> branch are fine and rebasing can let you get rid of those otherwise\n> ugly-and-frequent back-merges that users sometimes make.)\n\nThe \"minor exception\" is merging a topic branch into main, right? And\nthe \"ugly-and-frequent back-merges\" are the merges from main into a\ntopic branch?\n\nTao, the primary motivation behind the `git pull` warning was to help\nprevent users from merging main into a topic branch when that's not\nwhat they really want to do. The fact that novices sometimes do that\nhas been a point of pain for many people, including Linus Torvalds:\nSee \"Don't merge upstream code at random points\" at [1] and \"github\ncreates absolutely useless garbage merges\" at [2].\n\nIf you're seeing users merge main into topic branches without a good\nreason, that does sound like more of an education problem than a\nbad-defaults problem. We might still want to change the default to\nbetter support the more unusual cases, but if you're going for a quick\nwin, it would be faster to teach users the wisdom of not mixing rebase\nand merge in the first place.\n\n-Alex\n\n[1] https://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html\n[2] https://lore.kernel.org/lkml/CAHk-=wjbtip559HcMG9VQLGPmkurh5Kc50y5BceL8Q8=aL0H3Q@mail.gmail.com/\n"},{"id":"472374","messageId":"CAPMMpohd=sqP+RwyWZ7+nuGgYxELcOkxsLHpNc8BY0daN2uUbg@mail.gmail.com","threadId":"59200","inReplyTo":"CABPp-BFhvX6eg04+qTk7P64NfmUKnCTV7o1ufp447z6-XdUcJw@mail.gmail.com","subject":"Re: [PATCH] pull: conflict hint pull.rebase suggestion should offer \"merges\" vs \"true\"","fromName":"Tao Klerks","fromEmail":"tao@klerks.biz","sentAt":"2023-02-21T14:04:43Z","receivedAt":"2023-02-21T14:05:12Z","isPatch":true,"sender":{"key":"tao@klerks.biz","avatar":"https://avatars.githubusercontent.com/u/531704?v=4"},"body":"On Mon, Feb 20, 2023 at 5:56 PM Elijah Newren wrote:\n>\n> The strategies described by Buga and others in that mega-thread were\n> suboptimal solutions, in my opinion. Johannes went and implemented\n> some and found them wanting; see the thread over at\n> https://lore.kernel.org/git/nycvar.QRO.7.76.6.1804130002090.65@ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz/.\n\nAh, thank you! I think you had mentioned this before, and I somehow\nlost track of this.\n\nAt first I want to summarize this concern as \"any strategy that treats\na merge rebase as a *pair* of cherry-picks risks encountering\nnested/overlapping merge conflicts\", but I must be understanding too\nsuperficially, as you then mention arbitrary conflict nesting (and I\nassume this is not about octopus merges).\n\n> There were follow-ups with an improved strategy in the thread over at\n> https://lore.kernel.org/git/CABPp-BHWVO5VRhr1-Ou60F1wjKzJZ1e_dC01Mmzs+qB9kGayww@mail.gmail.com/\n> (Note that this route has also independently been discovered and\n> implemented in jj and found to work well, though it does handle\n> conflicts much differently). And I've since improved the strategy\n> further at https://github.com/newren/git/blob/e84f5f3585fd770ed21f398d2ae5f96e90a51b1e/replay-design-notes.txt#L264-L341.\n> However, note that this isn't a case of merely performing the proper\n> series of merges, it needs some specialized logic and some new\n> capabilities at the xdiff level.\n\nUnderstood - thanks for the update, and of course for all your\ncontinued work on this.\n\nIs it fair to say that, for the simple situations that Phillip's\ncherry-pick strategy *does* kick in for, the outcome should be exactly\nthe same as the outcome of the replay strategy?\n"},{"id":"472376","messageId":"CAPMMpohrEjZQwRbRAZfPfArNxEBDBzq8yJfsOAerhQ0qr6sWjQ@mail.gmail.com","threadId":"59200","inReplyTo":"CABPp-BEtXf9ja7Ec1fZ=BZwFDa+50zSAhtm3nN_=k+Nc2c=RXw@mail.gmail.com","subject":"Re: [PATCH] pull: conflict hint pull.rebase suggestion should offer \"merges\" vs \"true\"","fromName":"Tao Klerks","fromEmail":"tao@klerks.biz","sentAt":"2023-02-21T15:01:31Z","receivedAt":"2023-02-21T15:01:55Z","isPatch":true,"sender":{"key":"tao@klerks.biz","avatar":"https://avatars.githubusercontent.com/u/531704?v=4"},"body":"On Mon, Feb 20, 2023 at 6:21 PM Elijah Newren wrote:\n>\n>\n> When we teach new folks about git, and get to rebasing, there is a\n> simple and easy rule to tell users: don't mix merges and rebases.\n> (There's a minor exception there in that merges with the upstream\n> branch are fine and rebasing can let you get rid of those otherwise\n> ugly-and-frequent back-merges that users sometimes make.)\n\nWho is \"we\" here? When I search for the exact text \"don't mix merges\nand rebases\" in google, the only hit I get is this very email thread.\n\nWithout the quotes, I get a similar-looking page title, but I don't\nunderstand whether the author's thesis is the same thing you're\ngetting at - I don't think so:\nhttps://dev.to/jessekphillips/rebase-and-merge-don-t-mix-4aj\n\n>\n> Obviously, your users are ignoring that advice, and feeling pain.\n\n\"Ignoring\" is a strong (and in my opinion, strange) term to use here.\nThey are *not seeing* that advice, and I think you can reasonably\nassume that many, or most, users will not see almost any of the advice\nyou can possibly offer. As software designers I believe we all strive\nto set things up so you need to learn as little as possible to use\nsomething usefully, and safely.\n\n> To\n> be fair, the \"RECOVERING FROM UPSTREAM REBASE\" section of the rebase\n> manual isn't that prominent, and perhaps your users didn't have more\n> seasoned developers sharing this don't-mix-merges-and-rebases advice\n> with them. (It seemed to me to be shared pretty widely and commonly,\n> but perhaps we are relying on education from others too much and\n> education is never uniform if not coming from the tool itself.)\n\nMy equivalent of this is \"never rebase a shared branch unless you and\nyour team know what you're doing\". For most users I interact with,\nthat translates to \"don't use rebase at all unless you have a git\nveteran standing at your shoulder / on a screenshare with you\".\n\nThis advice is, again, not necessarily something that users even *see*\nbefore they start needing to use git. Maybe they should? Should we add\na child lock on the executable, \"this is likely to do very surprising\nthings, please sign here that you have studied graph theory and really\nunderstand how this stuff works before you get to use it\"?\n\n> I\n> understand you want to make it easier for users to avoid accidentally\n> getting into this state. That's a valid concern and desire. I think\n> we should improve the situation.\n>\n> However, on what timetable and at what cost to others?\n>\n> You're advocating we start advertising an alternate option, one which\n> has some caveats and gotchas that are not going to be so easy to\n> explain to users -- neither to new users, nor to folks who have been\n> using Git for years.\n\nWhat I'm trying to understand is whether or how these caveats and\ngotchas are *any worse than the status quo / than the current\n\"pull.rebase=true\" behavior*. I haven't understood any clear concrete\nways in which this is true yet:\n* \"pull.rebase=merges\" throws away your merge conflict resolutions -\nso does \"pull.rebase=merges\", right??\n* You might find it surprising that a same-merge-point branch gets\nrebased with the default \"-rno-rebase-cousins\" behavior... but\n\"pull.rebase=true\" will also do that!\n* You might be disappointed at the fact that an interactive\n--rebase-merges rebase fills your screen with stuff - but a\n\"flattening\" rebase does that too.\n* You might be disappointed at the fact that --rebase-merges takes a\nlong time when fast-forwarding over the merge of a large amount of\nhistory - but a \"flattening\" rebase does that too.\n\nI'm not advocating for experienced users being by any means required\nto use this functionality in its less-than-perfect state - but I *am*\narguing that foisting that less-than-ideal state on people who\ncopy-paste a suggested command from a pull conflict hint is far better\nthan allowing them to accidentally \"flatten the history\" of\nupstream-branch commits.\n\n> We could just bite the bullet and start\n> explaining, but these caveats and gotchas are completely incidental to\n> the implementation, and are in no-wise fundamental to the desired\n> operation.\n\nWe already *do* explain, right? We've already retired --preserve-merges!\n\n> I believe that switching to this new option is going to\n> generate an awful lot of questions and surprises by users. It seems\n> to me to be a really sad state of affairs to be recommending an option\n> with known defects when (IMO) the solution is known. Can't we fix it\n> first, then recommend it?\n\nI guess maybe I'm misunderstanding your concern:\n* My main aim is to stop users shooting themselves in the foot\n* If making --preserve-merges the overall default for \"git rebase\" is\nthe only or best way as Alex has proposed, great, let's do that. I\npersonally would like to have the \"use --rebase-merges by default when\nusing \"git rebase\" option that Alex is proposing even if we don't do\nthis, but even that is secondary to me compared with the \"stop\noffering a rebase behavior that will cause users to duplicate upstream\nhistory unknowingly, at a blocking prompt where you're forcing them to\npick *something*\" objective that kicked this off.\n* If there is another, better way of removing this foot-gun, I'm happy\nto explore another direction\n\nDo you have a suggestion? Or would you advocate for *eventually*\nreplacing the foot-gun with a more childsafe tool, when that tool is\nas sophisticated as we think it should eventually become?\n\n>\n> Granted, this is a trade-off. You have users experiencing real pain.\n> You want a solution now. I want to not recommend features with known\n> implementation shortcomings and known solutions, until those solutions\n> are implemented, and I know that will take a while. What to do here\n> is a judgement call, and I was merely giving my opinion on the call to\n> make. Other folks on the list might see things differently than I do.\n\nI think there are many options, and I'd love to understand which one\nyou advocate for in the immediate term, with respect to the specific\nissue I noted:\n\n* Replace the pull conflict hint only, as I initially proposed\n* Engage on an \"asap\" replacement of default \"git rebase\" behavior to\n\"--rebase-merges\" by default\n* Change the pull conflict hint in some other way (that removes the\ncopy-paste footgun)\n* Do nothing, accepting that we will revise all this in some future,\nand it's been like this for so long, what's wrong with a few more\npeople hitting the classic issues?\n* Some other proposal for short-term relief of this very specific problem?\n\nI should note here, that for \"my\" users, setting the new config option\nAlex proposes in \"rebase: add a config option for --rebase-merges\" by\ndefault, in all their repos, is sufficient for me to ensure people\nwill stop hurting themselves, and that's something I can easily do\nif/when the patch is accepted - but the main reason I hang out here is\nto try to advocate for users *like* mine, people who use git because\nit's the best or only game in town, rather than people like me who\nthink it's so friggin awesome and are fascinated to learn all its\narcane mysteries. In my environment, that's easily a 10:1 ratio. I\nsuspect that's a reasonable reflection on the universe of git users\ngenerally.\n"},{"id":"472377","messageId":"CAPMMpohfF5Cwgxt_G+Gp4rNPGTJZcQfmgEoJcFi_Kzbv2XGuog@mail.gmail.com","threadId":"59200","inReplyTo":"CAMMLpeSZs8DqrN6_F9-eg7fcbjV-O5+3V+hUsOhyd0x10xsCaQ@mail.gmail.com","subject":"Re: [PATCH] pull: conflict hint pull.rebase suggestion should offer \"merges\" vs \"true\"","fromName":"Tao Klerks","fromEmail":"tao@klerks.biz","sentAt":"2023-02-21T15:40:04Z","receivedAt":"2023-02-21T15:41:31Z","isPatch":true,"sender":{"key":"tao@klerks.biz","avatar":"https://avatars.githubusercontent.com/u/531704?v=4"},"body":"On Mon, Feb 20, 2023 at 7:33 PM Alex Henrie wrote:\n>\n> Tao, the primary motivation behind the `git pull` warning was to help\n> prevent users from merging main into a topic branch when that's not\n> what they really want to do. The fact that novices sometimes do that\n> has been a point of pain for many people, including Linus Torvalds:\n> See \"Don't merge upstream code at random points\" at [1] and \"github\n> creates absolutely useless garbage merges\" at [2].\n>\n> If you're seeing users merge main into topic branches without a good\n> reason, that does sound like more of an education problem than a\n> bad-defaults problem.\n\nI would disagree on two points:\n\n1. The need for merging in the upstream varies project by project,\nuser by user, etc. If you are working on a part of a system where you\ncan reasonably assume the ground will not shift under your feet,\nawesome, lucky you! Many users are not so fortunate, and need to\nregularly ensure that their changes still make sense in the\never-changing upstream context.\n\nRegularly (whatever that means to you) merging in the upstream is the\nsimplest way of achieving that. If you're working on your own or as\npart of a team that's happy to handle coordinated rebasing, then\nrebasing is a potentially-more-satisfying way of achieving the same\nend - either way, assuming that their changes will make sense in the\nupstream context is simply not a luxury many users can afford over any\nperiod of time.\n\nNow, you note that Linus advocates for merging specific points,\nbecause he doesn't respect you merging \"random crap\" from a branch\ncalled \"linus\" - that's fine, but many projects strive to keep a\nspecific trunk branch \"evergreen\" in order to minimize late conflicts\nare maximize coordination - there's a pretty cool site about it:\nhttps://trunkbaseddevelopment.com/ - this is not really different to\nLinus' advice except that the goal is to make there *never* be \"random\ncrap\" on the upstream.\n\n2. The fact that the commit history of non-expert git users (those who\nshould not be using rebase, especially in teams) are so often...\nspidery... is why the \"Squash\" option of pull requests / merge\nrequests is so popular in centralized workflows (GitHub, GitLab,\nBitBucket, etc).\n\nIf your project follows a \"merge down, squash up\" strategy with a\nwell-CI-guarded evergreen trunk on a central server, there's simply no\nreason to *require* your users to become rebasing experts - you can\nlet them use simple merge-based workflows, keep your trunk clean by\nsquashing away their complex commit graphs, let them merge down\nwhenever they need or want to, etc.\n\n\n> We might still want to change the default to\n> better support the more unusual cases, but\n\nDo we have any analysis/understanding of how common workflows like\nthat of the git or linux projects are, vs github-style fork-based\nprojects, vs straight-up single central server projects?\n\nI'm not sure what you mean by \"unusual\", but I don't think \"avoid\nrebase unless you really know what you're doing, merge down at will,\nwe will squash your contribution in the pull/merge request at the end\nanyway\" is an unusual flow at all nowadays.\n\n> if you're going for a quick\n> win, it would be faster to teach users the wisdom of not mixing rebase\n> and merge in the first place.\n>\n\n\"teach [...] wisdom\" is a good one! No, seriously - of course I'm\ngoing to do the best I can to prevent my users from falling into the\ntraps surrounding them - but my point here is that *we simply\nshouldn't have pointless traps*. Offering a command that can cause\nsignificant \"harm\" (time loss, frustration, etc), silently... just\ndoesn't seem like a good idea.\n\n\n> [1] https://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html\n> [2] https://lore.kernel.org/lkml/CAHk-=wjbtip559HcMG9VQLGPmkurh5Kc50y5BceL8Q8=aL0H3Q@mail.gmail.com/\n"},{"id":"472387","messageId":"CAMMLpeR0Z1Ay_ubHuGVz4f5RfxhhmoKsNq=OsaL5TB3WHXfJvA@mail.gmail.com","threadId":"59200","inReplyTo":"CAPMMpohfF5Cwgxt_G+Gp4rNPGTJZcQfmgEoJcFi_Kzbv2XGuog@mail.gmail.com","subject":"Re: [PATCH] pull: conflict hint pull.rebase suggestion should offer \"merges\" vs \"true\"","fromName":"Alex Henrie","fromEmail":"alexhenrie24@gmail.com","sentAt":"2023-02-21T17:45:19Z","receivedAt":"2023-02-21T17:46:08Z","isPatch":true,"sender":{"key":"alexhenrie24@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5951993?v=4"},"body":"On Tue, Feb 21, 2023 at 8:40 AM Tao Klerks wrote:\n>\n> 2. The fact that the commit history of non-expert git users (those who\n> should not be using rebase, especially in teams) are so often...\n> spidery... is why the \"Squash\" option of pull requests / merge\n> requests is so popular in centralized workflows (GitHub, GitLab,\n> BitBucket, etc).\n>\n> If your project follows a \"merge down, squash up\" strategy with a\n> well-CI-guarded evergreen trunk on a central server, there's simply no\n> reason to *require* your users to become rebasing experts - you can\n> let them use simple merge-based workflows, keep your trunk clean by\n> squashing away their complex commit graphs, let them merge down\n> whenever they need or want to, etc.\n\nThe advantage to that workflow is that you don't have to teach users\nhow to rebase. (Whether the actual process of merging or rebasing is\neasier, assuming that the user knows how to do both, is debatable and\nlikely depends a lot on the particular situation.) The disadvantage is\nthat even merge requests that seem like they only need one commit\noften turn into multiple commits, and squashing all of those commits\ntogether indiscriminately both makes it harder for the reviewer to\nfollow the progression of steps the developer took and decreases the\nusefulness of tools like `git blame` and `git bisect`. For example,\nthe patch series that I sent to add a rebase.merges option will be 3\nor 4 commits in the end, and other developers have good reasons to ask\nme to keep those commits separate instead of squashing them all into a\nsingle patch. On top of that, if your developers get the impression\nthat all projects on GitHub/GitLab/whatever use the same workflow,\nthey are likely to cause headaches when they present spidery merge\nrequests to other projects. If you are OK with those tradeoffs then\nthat's fine, Git will support you. My point is simply that every\nworkflow has its advantages and disadvantages, and there's no workflow\nthat solves every problem.\n\n> Do we have any analysis/understanding of how common workflows like\n> that of the git or linux projects are, vs github-style fork-based\n> projects, vs straight-up single central server projects?\n\nI don't have any statistics (although I would love to see them if they\nexist), but I do know that all of these workflows are common enough\nthat `git pull` can't assume what the user wants. The warning exists\nto try to prevent the user from shooting themself in the foot.\n\n> I'm not sure what you mean by \"unusual\", but I don't think \"avoid\n> rebase unless you really know what you're doing, merge down at will,\n> we will squash your contribution in the pull/merge request at the end\n> anyway\" is an unusual flow at all nowadays.\n\nThe unusual cases are the ones where you mix merge and rebase on your\nown topic branch. Your developers did that accidentally (despite `git\npull` trying to warn them) and suffered because of it, because it\nisn't well supported right now. I think we all agree that it should be\nbetter supported, we just disagree on how to get there.\n\n-Alex\n"},{"id":"472442","messageId":"87a615vkqk.fsf@osv.gnss.ru","threadId":"59200","inReplyTo":"CAPMMpogi_QoGKD824JW+85v_Sgaf5d3TAd_P55YyT5NF6AUJ=w@mail.gmail.com","subject":"Re: [PATCH] pull: conflict hint pull.rebase suggestion should offer \"merges\" vs \"true\"","fromName":"Sergey Organov","fromEmail":"sorganov@gmail.com","sentAt":"2023-02-22T14:27:15Z","receivedAt":"2023-02-22T14:27:23Z","isPatch":true,"sender":{"key":"sorganov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8501568?v=4"},"body":"Tao Klerks writes:\n\n> On Sat, Feb 18, 2023 at 5:39 PM Phillip Wood wrote:\n>>\n>> On 18/02/2023 03:17, Elijah Newren wrote:\n\n[...]\n\n>> > My personal opinion would be adding such a capability should be step\n>> > 2.5 in your list, though I suspect that would make Tao unhappy (it's a\n>> > non-trivial amount of work, unlike the other steps in your list).\n>>\n>> I've got a couple of patches[1] that cherry-pick the merge if only one\n>> of the parents has changed. I've never tried upstreaming them as it is\n>> only a partial solution to the problem of rebasing merges but that\n>> approach should work well with \"git pull --rebase=merges\" as only the\n>> upstream side will have changed (when rebasing my git integration branch\n>> with that patch the merges are cherry-picked). They might make a useful\n>> starting point if anyone wants to try and improve the rebasing of merges.\n>>\n>\n> This is awesome!\n>\n> It feels like the first step towards the general strategy that was (I\n> believe) best described by Buga at\n> https://public-inbox.org/git/a0cc88d2-bfed-ce7b-1b3f-3c447d2b32da@gmail.com/\n> !\n\nBeing the provoker of all the fuss then, as well as the author of basic\noriginal method, I agree Buga has summarized and described all the ideas\nin existence at that time extremely well.\n\n>\n> (unless I'm missing something, the result of this is exactly the same\n> as the result of that strategy, in these \"simple\" cases where it kicks\n> in)\n>\n> The one concern I have with this is that, *if I understand correctly*,\n> it sometimes throws away the existing merge information, and sometimes\n> doesn't, and there's no easy way to know which it is at runtime.\n\nAs far as I'm aware, it's not the case. The originally described method\nindeed misbehaved, but this simple mistake has been quickly fixed, and\nthe description by Buga you've referenced already discusses updated\nversion.\n\n> Would adding a warning on stderr when a both-parents merge is\n> encountered (and any merge resolutions or related changes are still\n> discarded) be enough to make this shippable?\n\nEven if there are in fact such corner cases, we could make ourselves\nvery cautious and stop even after non-conflicting rebase, if we detect\nthat U1' and U2' don't match, and let user decide if the result is\nacceptable (similar to what rerere does on successful application of\nreplayed resolutions).\n\nI also agree (in particular with Buga) that from the POV of user\nexperience the method suggested by Phillip should be superior, as it\nemphasizes the natural dominance of the \"current branch\", as opposed to\noriginally described symmetric method that is more suitable for formal\nanalysis than for actual convenient implementation. Yet creating U1' and\nU2' from the original method could be useful for the purpose of checking\nfor possible problems with automatic rebase that the user may need to be\naware of.\n\nThe biggest problem here, as I see it, is designing UI that'd make sense\nin the case of conflicts in multiple stages of the suggested algorithms,\nbut I think we can simplify it for now by stopping and suggesting blind\nre-merge in case of any conflict but that on rebasing of changes to the\nfirst parent. Even this would be a huge step forward compared to silent\ndrop of merge commits and blindly re-merging of updated parents.\n\n>\n> Are there *any* circumstances where the new cherry-picking behavior\n> introduced here wouldn't be the right thing to have happen?\n\nNone that I'm aware off, but I admit I'm not familiar with later Elijah\nwork on the subject, so I could be mistaken. I only got a sketchy look\nat what Elijah did, and it looks like advanced material to me. I'd\nincline to rather get solid implementation of basics first, probably\nusing Phillip method, then consider advanced methods if practice reveals\ndemands for further improvements.\n\nI'm afraid that there is no ideal general solution for the problem of\nrebasing merge commits, so we need to limit ourselves and get a\npractical one that has already been described.\n\nOverall, I'd love to finally have reliable Git behavior when rebasing\nmerge commits, even though I've already got a habit to perform all the\nmerges in 2 steps: auto-merge resolving textual conflicts only (if any),\nfollowed by a fixup for semantics conflicts (if any).\n\nThanks,\n-- Sergey Organov\n\n"},{"id":"472639","messageId":"CABPp-BGqAxKnxDRVN4cYMteLp33hvto07R3=TJBT5WubJT4+Og@mail.gmail.com","threadId":"59200","inReplyTo":"CAPMMpohrEjZQwRbRAZfPfArNxEBDBzq8yJfsOAerhQ0qr6sWjQ@mail.gmail.com","subject":"Re: [PATCH] pull: conflict hint pull.rebase suggestion should offer \"merges\" vs \"true\"","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2023-02-24T07:06:13Z","receivedAt":"2023-02-24T07:06:51Z","isPatch":true,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Tue, Feb 21, 2023 at 7:01 AM Tao Klerks wrote:\n>\n> On Mon, Feb 20, 2023 at 6:21 PM Elijah Newren wrote:\n> >\n[...]\n> > Obviously, your users are ignoring that advice, and feeling pain.\n>\n> \"Ignoring\" is a strong (and in my opinion, strange) term to use here.\n> They are *not seeing* that advice, and I think you can reasonably\n> assume that many, or most, users will not see almost any of the advice\n> you can possibly offer. As software designers I believe we all strive\n> to set things up so you need to learn as little as possible to use\n> something usefully, and safely.\n\nYep, fair enough.\n\n> > We could just bite the bullet and start\n> > explaining, but these caveats and gotchas are completely incidental to\n> > the implementation, and are in no-wise fundamental to the desired\n> > operation.\n>\n> We already *do* explain, right? We've already retired --preserve-merges!\n\nBut we didn't suggest either `--preserve-merges` or `--rebase-merges`\nto general users. The only ones who used it went looking for it.\nThat's fundamentally different than recommending it to all new and\nmany existing Git users.\n\n> > Granted, this is a trade-off. You have users experiencing real pain.\n> > You want a solution now. I want to not recommend features with known\n> > implementation shortcomings and known solutions, until those solutions\n> > are implemented, and I know that will take a while. What to do here\n> > is a judgement call, and I was merely giving my opinion on the call to\n> > make. Other folks on the list might see things differently than I do.\n>\n> I think there are many options, and I'd love to understand which one\n> you advocate for in the immediate term, with respect to the specific\n> issue I noted:\n>\n> * Replace the pull conflict hint only, as I initially proposed\n> * Engage on an \"asap\" replacement of default \"git rebase\" behavior to\n> \"--rebase-merges\" by default\n> * Change the pull conflict hint in some other way (that removes the\n> copy-paste footgun)\n> * Do nothing, accepting that we will revise all this in some future,\n> and it's been like this for so long, what's wrong with a few more\n> people hitting the classic issues?\n> * Some other proposal for short-term relief of this very specific problem?\n\nMy personal opinion is that we should avoid long term problems for\nusers and maintainers of rebasing merges by pushing it too early to\ntoo many folks. For short term relief, I would suggest some mixture\nof the following are worth looking into:\n * Attempt to improve the message shown to users, perhaps referring\nthem to somewhere in the docs that point out advantages and\ndisadvantages of each choice.\n * Possibly make the message shown to users be \"smart\" rather than\nhardcoded. For example, you could check the local-only portion of\nhistory; if there are no merge commits, or if the upstream branch is\n\"origin/main\" and the only merges within the local-only history are\n'Merge branch \"origin/main\"...' then suggesting a regular rebase is\nfine. If there are other merges, then adapt the wording (and perhaps\nin that special case, actually bringing up rebasing merges is okay,\nthough it'd still be nice if the docs with advantages/disadvantages\npointed out its shortcomings). This might be an expensive check, but\nif only users who haven't configured pull. have to pay for\nit, then perhaps it's a useful thing to spend cycles on.\n\n> I should note here, that for \"my\" users, setting the new config option\n> Alex proposes in \"rebase: add a config option for --rebase-merges\" by\n> default, in all their repos, is sufficient for me to ensure people\n> will stop hurting themselves, and that's something I can easily do\n> if/when the patch is accepted - but the main reason I hang out here is\n> to try to advocate for users *like* mine, people who use git because\n> it's the best or only game in town, rather than people like me who\n> think it's so friggin awesome and are fascinated to learn all its\n> arcane mysteries. In my environment, that's easily a 10:1 ratio. I\n> suspect that's a reasonable reflection on the universe of git users\n> generally.\n\nYes, I understand. It's frustrating when something you need isn't\nthere and we only have a suboptimal approximation. I want to make\nthings better and have put a lot of time into it; some things that\nalready went into merge-ort were designed around this problem space\nand I'm planning to do more here.\n\nBut, also, remember that I'm only one voice among many. Others may\ndisagree with me and agree with you on pushing this earlier.\n"},{"id":"472640","messageId":"CABPp-BH2XPB4BN5Oo=VnLav_wvAGGUAyZC4HRHRRmES5k75P1Q@mail.gmail.com","threadId":"59200","inReplyTo":"87a615vkqk.fsf@osv.gnss.ru","subject":"Re: [PATCH] pull: conflict hint pull.rebase suggestion should offer \"merges\" vs \"true\"","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2023-02-24T07:06:29Z","receivedAt":"2023-02-24T07:06:59Z","isPatch":true,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Wed, Feb 22, 2023 at 6:27 AM Sergey Organov wrote:\n>\n> Tao Klerks writes:\n>\n> > On Sat, Feb 18, 2023 at 5:39 PM Phillip Wood wrote:\n> >>\n> >> On 18/02/2023 03:17, Elijah Newren wrote:\n\n[...]\n\n> I also agree (in particular with Buga) that from the POV of user\n> experience the method suggested by Phillip should be superior, as it\n> emphasizes the natural dominance of the \"current branch\", as opposed to\n> originally described symmetric method that is more suitable for formal\n> analysis than for actual convenient implementation. Yet creating U1' and\n> U2' from the original method could be useful for the purpose of checking\n> for possible problems with automatic rebase that the user may need to be\n> aware of.\n>\n> The biggest problem here, as I see it, is designing UI that'd make sense\n> in the case of conflicts in multiple stages of the suggested algorithms,\n> but I think we can simplify it for now by stopping and suggesting blind\n> re-merge in case of any conflict but that on rebasing of changes to the\n> first parent. Even this would be a huge step forward compared to silent\n> drop of merge commits and blindly re-merging of updated parents.\n\nI'm not so sure it's a huge step forward. Or even a step forward.\n\nDscho actually implemented the old proposals and tried them out, as\nmentioned in the threads I linked to. The results on balance were\nsignificantly worse to him than just throwing away the previous merge\nresolution information and redoing the merge from scratch. He really\nwanted a better solution, but the previous proposals didn't provide\nit.\n\nThis newer approximation, while more careful about only attempting to\nrun in specific cases and having some good ideas to improve the user\nexperience, still builds on the problematic foundations in those old\nsuggestions (namely, cherry-picking merges relative to either of their\nparents). I think it isn't careful enough about the subset of cases\nwhere those problematic foundations can work right.\n\n> > Are there *any* circumstances where the new cherry-picking behavior\n> > introduced here wouldn't be the right thing to have happen?\n\nYes, I can think of one fairly readily: Do an interactive rebase and\ndrop one or more commits on the side-branch being merged. This\ncherry-picking of merges would reinstate those dropped changes via\nsilently squashing them into the merge commit itself, making for a\nrather evil merge.\n\n> None that I'm aware off, but I admit I'm not familiar with later Elijah\n> work on the subject, so I could be mistaken. I only got a sketchy look\n> at what Elijah did, and it looks like advanced material to me. I'd\n> incline to rather get solid implementation of basics first, probably\n> using Phillip method, then consider advanced methods if practice reveals\n> demands for further improvements.\n\nThat'd be fine if there's another solution that can provide a \"solid\nimplementation of the basics\"; I've not seen another proposal that can\nyet.\n\n> I'm afraid that there is no ideal general solution for the problem of\n> rebasing merge commits.\n\nSometimes problems aren't generically solvable. However, sometimes\nthe problem is solvable, but folks so far have only provided solutions\nbuilt on a faulty basis, or that were only designed for special cases,\nor that only look at a subset of the problem space.\n\nI think rebasing merges falls into the latter category, and that the\nprior proposals were just off the mark. Granted, I haven't\nimplemented my proposal yet and I might discover more issues when I\ndo, but I'm optimistic. It just really needs some good uninterrupted\ntime, and my Git time comes in highly interrupted occasional spurts\nthese days (and with new short-term priorities being inserted based on\nother things that come up on the mailing list and from elsewhere to\nboot). But I'll get to it one way or another.\n"},{"id":"472679","messageId":"87bklilnvp.fsf@osv.gnss.ru","threadId":"59200","inReplyTo":"CABPp-BH2XPB4BN5Oo=VnLav_wvAGGUAyZC4HRHRRmES5k75P1Q@mail.gmail.com","subject":"Re: [PATCH] pull: conflict hint pull.rebase suggestion should offer \"merges\" vs \"true\"","fromName":"Sergey Organov","fromEmail":"sorganov@gmail.com","sentAt":"2023-02-24T22:06:18Z","receivedAt":"2023-02-24T22:06:28Z","isPatch":true,"sender":{"key":"sorganov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8501568?v=4"},"body":"Elijah Newren writes:\n\n> On Wed, Feb 22, 2023 at 6:27 AM Sergey Organov wrote:\n>>\n>> Tao Klerks writes:\n>>\n>> > On Sat, Feb 18, 2023 at 5:39 PM Phillip Wood wrote:\n>> >>\n>> >> On 18/02/2023 03:17, Elijah Newren wrote:\n>\n> [...]\n>\n>> I also agree (in particular with Buga) that from the POV of user\n>> experience the method suggested by Phillip should be superior, as it\n>> emphasizes the natural dominance of the \"current branch\", as opposed to\n>> originally described symmetric method that is more suitable for formal\n>> analysis than for actual convenient implementation. Yet creating U1' and\n>> U2' from the original method could be useful for the purpose of checking\n>> for possible problems with automatic rebase that the user may need to be\n>> aware of.\n>>\n>> The biggest problem here, as I see it, is designing UI that'd make sense\n>> in the case of conflicts in multiple stages of the suggested algorithms,\n>> but I think we can simplify it for now by stopping and suggesting blind\n>> re-merge in case of any conflict but that on rebasing of changes to the\n>> first parent. Even this would be a huge step forward compared to silent\n>> drop of merge commits and blindly re-merging of updated parents.\n>\n> I'm not so sure it's a huge step forward. Or even a step forward.\n\nGit currently throws away my precious merges! Silently! How it's not a\nstep forward to stop doing this?! Sorry for getting that heated :)\n\nGit is well-known for being extremely careful with user content, and\nthere is the only case where it fails miserably: rebasing merges. The\nabove method will simply fix this long-standing deficiency that is even\nmore dangerous as users do trust Git so much.\n\nI can only tell that I, for example, will definitely benefit a lot once\nit is implemented, as currently a rebase containing merge is at roughly\nthe same level of risk as \"cvs update\" was in the old days: run and keep\nyour fingers crossed. Well, with Git it's unless you are careful to do\n2-step merge-fixup thingy every time you merge, that is basically just\npoor man attempt at fighting long-standing Git weakness.\n\n> Dscho actually implemented the old proposals and tried them out, as\n> mentioned in the threads I linked to. The results on balance were\n> significantly worse to him than just throwing away the previous merge\n> resolution information and redoing the merge from scratch. He really\n> wanted a better solution, but the previous proposals didn't provide\n> it.\n\nOTOH, Buga has sketched the proposals, confirmed problem with my\noriginal one (that Dscho predicted), then sketched the update I came up\nwith, and showed it does work in common cases as expected.\n \nThat said, I'm almost sure that for any method of rebasing and/or\nmerging of whatever, one motivated enough will be able to find corner\ncases where the method fails, yet we do have both merges and rebases in\nGit, and rebasing of merges falls to the same category. We need them.\nMerges need to be properly rebased, not silently replaced with\n(different) merges, unless user asks for re-merge explicitly. To me\nDscho (or anybody else) finding rough cases is an expected outcome, and\nis not a convincing argument against the feature.\n\nAs for Dscho results specifically, I've got an impression that he never\nneeded rebasing of merges in the first place, and re-merging always\nsuited him just fine, so it'd be rather a surprise if rebasing of merges\nsuddenly started to work better for his needs and workflows once he has\nimplemented it.\n\nThat said, when better method(s) of rebasing of merges will be found,\nI'm sure they'll be adopted, but for now I do believe we need something\nreliable that has been checked to actually work for common cases, as\nblind re-merging simply does not, and I still suspect the best choice\nfor the time being is Phillip's incremental method.\n\nOverall, I'm still in desperate need for my precious merge-the-commits\nbe rebased, and not replaced with Git idea of how merge commit would\nlook if [current version of] 'git-merge' algorithm merged my branch in\n[using Git current default settings]. It's my dream that Git finally\nstops silently substituting a result of 'git-merge'\n(just-a-helper-operation intended to simplify creation of merge commits)\nfor actual merge-the-commit that is part of my content.\n\nBest regards,\n-- Sergey Organov\n"},{"id":"472690","messageId":"CABPp-BHRbKG_cXdwaPT0-Rj6QTkkJRcT4N0f45==i7oAqiTC+w@mail.gmail.com","threadId":"59200","inReplyTo":"87bklilnvp.fsf@osv.gnss.ru","subject":"Re: [PATCH] pull: conflict hint pull.rebase suggestion should offer \"merges\" vs \"true\"","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2023-02-24T23:59:36Z","receivedAt":"2023-02-24T23:59:54Z","isPatch":true,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Fri, Feb 24, 2023 at 2:06 PM Sergey Organov wrote:\n>\n> Elijah Newren writes:\n>\n> > On Wed, Feb 22, 2023 at 6:27 AM Sergey Organov wrote:\n\n> >> I also agree (in particular with Buga) that from the POV of user\n> >> experience the method suggested by Phillip should be superior.\n> >> [...]\n> >> Even this would be a huge step forward compared to silent\n> >> drop of merge commits and blindly re-merging of updated parents.\n> >\n> > I'm not so sure it's a huge step forward. Or even a step forward.\n>\n> Git currently throws away my precious merges! Silently! How it's not a\n> step forward to stop doing this?! Sorry for getting that heated :)\n\nI totally agree with you that we have a big problem. No need to\nconvince me on that. :-)\n\nBut having a big problem does not imply we have to implement and ship\nthe first proposal that comes along to change things. Or second, or\nthird. Such proposals might actually make things even worse. You\ncorrectly point out that we do not need to require perfection, but we\ncan and should require that the proposed solutions not only make some\nthings better but that they make things better overall.\n\nAnd in order to convincingly persuade others to adopt various\nproposals, we should be aware of what the advantages and shortcomings\nare...at least the ones that have already been discovered and\npublicized, and be able to talk about those shortcomings candidly.\n\n> As for Dscho results specifically, I've got an impression that he never\n> needed rebasing of merges in the first place, and re-merging always\n> suited him just fine, so it'd be rather a surprise if rebasing of merges\n> suddenly started to work better for his needs and workflows once he has\n> implemented it.\n\nAre you serious?\n\nYou're claiming the author of --preserve-merges; and the author of\n--rebase-merges; and someone who actually implemented the ideas you,\nBuga, and Phillip were all discussing to improve rebasing of\nmerges[1]; and who maintains a project (Git for Windows) that has\ncountless branches with hundreds of commits and myriad merge points\nand needs to rebase the whole lot as Git is updated...is someone who\ndoesn't actually care about rebasing of merges?\n\nI thought you had tried to read up on this subject and were commenting\nin good faith, but I'm starting to have my doubts.\n\nPlease, go read at least [1] to see Johannes comments about how the\nprior proposals don't work beyond simple cases. He didn't discard\nthose ideas because he didn't care about the useful information in\nmerge commits, he discarded them because in practice those ideas\nresulted in behavior that was *even worse* than the current big\nproblems.\n\n[1] https://lore.kernel.org/git/nycvar.QRO.7.76.6.1804130002090.65@ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz/\n\n[...]\n> for now I do believe we need something\n> reliable that has been checked to actually work for common cases, as\n> blind re-merging simply does not.\n\nI agree with you. The word \"reliable\" is particularly key, and IMO\nrules out any suggestion that involves applying the diff between a\nmerge commit and either of its parents. Not only do I think it's the\nwrong solution theoretically, I also think they have empirically been\nshown to provide problems that many will consider to be as bad or\nworse than our current poison. I obviously don't have veto power or\nanything close to it, but in my opinion any solution based on those\nideas do not meet the threshold bar for inclusion in Git and I'll\nraise my voice against them.\n\nSolutions based on other ideas are fair game. Heck, I've proposed one\nand I know of simpler variants to my proposal. Other solutions may\nexist too. But can we stop pushing already discredited proposals and\ninstead reach for something that has a more solid foundation?\n"},{"id":"472723","messageId":"87fsatixnn.fsf@osv.gnss.ru","threadId":"59200","inReplyTo":"CABPp-BHRbKG_cXdwaPT0-Rj6QTkkJRcT4N0f45==i7oAqiTC+w@mail.gmail.com","subject":"Re: [PATCH] pull: conflict hint pull.rebase suggestion should offer \"merges\" vs \"true\"","fromName":"Sergey Organov","fromEmail":"sorganov@gmail.com","sentAt":"2023-02-25T15:15:40Z","receivedAt":"2023-02-25T15:15:47Z","isPatch":true,"sender":{"key":"sorganov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8501568?v=4"},"body":"Elijah Newren writes:\n\n> On Fri, Feb 24, 2023 at 2:06 PM Sergey Organov wrote:\n>>\n>> Elijah Newren writes:\n\n[...]\n\n> Please, go read at least [1] to see Johannes comments about how the\n> prior proposals don't work beyond simple cases.\n\nIt's exactly handling of simple cases that we need most. We can get\nfancy afterwards, if feasible.\n\nThanks,\n-- Sergey Organov\n"},{"id":"472724","messageId":"CABPp-BF3JUg4jThS8Y_3v-tOEey55V_9KpXRZ3HvfaC3S2m=GQ@mail.gmail.com","threadId":"59200","inReplyTo":"87fsatixnn.fsf@osv.gnss.ru","subject":"Re: [PATCH] pull: conflict hint pull.rebase suggestion should offer \"merges\" vs \"true\"","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2023-02-25T16:28:49Z","receivedAt":"2023-02-25T16:29:06Z","isPatch":true,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Sat, Feb 25, 2023 at 7:15 AM Sergey Organov wrote:\n>\n> Elijah Newren writes:\n>\n> > On Fri, Feb 24, 2023 at 2:06 PM Sergey Organov wrote:\n> >>\n> >> Elijah Newren writes:\n>\n> [...]\n>\n> > Please, go read at least [1] to see Johannes comments about how the\n> > prior proposals don't work beyond simple cases.\n>\n> It's exactly handling of simple cases that we need most. We can get\n> fancy afterwards, if feasible.\n\nIf we can handle just the simple cases without making common cases\nsignificantly worse, that'd be a potential path forward. Any proposal\ninvolving the diff between a merge commit and either of its parents\n(or an equivalent such as a three-way merge involving the merge commit\nand one of its parents) doesn't achieve that, IMO.\n"},{"id":"472742","messageId":"87lekklqpi.fsf@osv.gnss.ru","threadId":"59200","inReplyTo":"CABPp-BF3JUg4jThS8Y_3v-tOEey55V_9KpXRZ3HvfaC3S2m=GQ@mail.gmail.com","subject":"Re: [PATCH] pull: conflict hint pull.rebase suggestion should offer \"merges\" vs \"true\"","fromName":"Sergey Organov","fromEmail":"sorganov@gmail.com","sentAt":"2023-02-26T09:29:45Z","receivedAt":"2023-02-26T09:29:55Z","isPatch":true,"sender":{"key":"sorganov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8501568?v=4"},"body":"Elijah Newren writes:\n\n> On Sat, Feb 25, 2023 at 7:15 AM Sergey Organov wrote:\n>>\n>> Elijah Newren writes:\n>>\n>> > On Fri, Feb 24, 2023 at 2:06 PM Sergey Organov wrote:\n>> >>\n>> >> Elijah Newren writes:\n>>\n>> [...]\n>>\n>> > Please, go read at least [1] to see Johannes comments about how the\n>> > prior proposals don't work beyond simple cases.\n>>\n>> It's exactly handling of simple cases that we need most. We can get\n>> fancy afterwards, if feasible.\n>\n> If we can handle just the simple cases without making common cases\n> significantly worse, that'd be a potential path forward. Any proposal\n> involving the diff between a merge commit and either of its parents\n> (or an equivalent such as a three-way merge involving the merge commit\n> and one of its parents) doesn't achieve that, IMO.\n\nExcept the method discussed does achieve exactly that according to the\nevidence gathered at the time of debates, and here is confirmation (from\nJohannes himself) from the reference you provided:\n\n\"This strategy, while it performed well in my initial tests (and in\nBuga's initial tests, too), *does* involve more than one 3-way merge,\nand therefore it risks something very, very nasty: *nested* merge\nconflicts.\"\n\nSo, overall, the method performs well in general, and we just need to\navoid driving ourselves into nested merge conflicts, as resolving them\nis beyond capabilities of most human beings.\n\nSetting this back into perspective, in comparison to blind re-merge,\nthat fails to keep user changes even when no conflicts at all exist, and\neven when it's applied at the same place in the history, the discussed\nmethod is a *huge* step forward, especially if re-merge is kept as a\nfallback strategy.\n\nP.S. BTW, where this hate for using of diffs with respect to parents\ncome from, I wonder, provided we do use them all the time anyway?\n\nThanks,\n-- Sergey Organov\n"},{"id":"472781","messageId":"CABPp-BGJ+jdwizBNyYr-st58F6BPbyrJ+DwRX81_0NjgU6LhzA@mail.gmail.com","threadId":"59200","inReplyTo":"87lekklqpi.fsf@osv.gnss.ru","subject":"Re: [PATCH] pull: conflict hint pull.rebase suggestion should offer \"merges\" vs \"true\"","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2023-02-27T15:20:54Z","receivedAt":"2023-02-27T15:21:17Z","isPatch":true,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Sun, Feb 26, 2023 at 1:29 AM Sergey Organov wrote:\n>\n> Elijah Newren writes:\n>\n> > On Sat, Feb 25, 2023 at 7:15 AM Sergey Organov wrote:\n> >>\n> >> Elijah Newren writes:\n> >>\n> >> > On Fri, Feb 24, 2023 at 2:06 PM Sergey Organov wrote:\n> >> >>\n> >> >> Elijah Newren writes:\n> >>\n> >> [...]\n> >>\n> >> > Please, go read at least [1] to see Johannes comments about how the\n> >> > prior proposals don't work beyond simple cases.\n> >>\n> >> It's exactly handling of simple cases that we need most. We can get\n> >> fancy afterwards, if feasible.\n> >\n> > If we can handle just the simple cases without making common cases\n> > significantly worse, that'd be a potential path forward. Any proposal\n> > involving the diff between a merge commit and either of its parents\n> > (or an equivalent such as a three-way merge involving the merge commit\n> > and one of its parents) doesn't achieve that, IMO.\n>\n> Except the method discussed does achieve exactly that according to the\n> evidence gathered at the time of debates, and here is confirmation (from\n> Johannes himself) from the reference you provided:\n\nI'm glad you read it. :-)\n\n> \"This strategy, while it performed well in my initial tests (and in\n> Buga's initial tests, too), *does* involve more than one 3-way merge,\n> and therefore it risks something very, very nasty: *nested* merge\n> conflicts.\"\n>\n> So, overall, the method performs well in general,\n\nJumping from \"performed well on initial tests\" to \"performs well in\ngeneral\" seems to me to be quite a large and unwarranted logical leap.\n\n> and we just need to\n> avoid driving ourselves into nested merge conflicts\n\nI'm glad you're discussing a disadvantage and how to address it, but I\ndon't understand how you can jump to the implication that this is the\nonly one.\n\n> Setting this back into perspective, in comparison to blind re-merge,\n> that fails to keep user changes even when no conflicts at all exist, and\n> even when it's applied at the same place in the history, the discussed\n> method is a *huge* step forward, especially if re-merge is kept as a\n> fallback strategy.\n\nThe use of superlatives and asterisks doesn't change my opinion; I'm\nstill skeptical that the given strategy is overall a step forward, let\nalone a large one.\n\n(I do agree we have a huge problem and thus that a huge step forward\ntheoretically could be taken, I just don't see this as it.)\n\n> P.S. BTW, where this hate for using of diffs with respect to parents\n> come from, I wonder, provided we do use them all the time anyway?\n\nI have no hate for such diffs; I just firmly believe they are\ninappropriate as a solution for the particular problem space being\ndiscussed.\n\nBut I've stated that more than enough, and no one is producing patches\non this topic right now, so I'll drop out of this thread. I still\nbelieve in my proposed solution, and I'll implement it as I get time\nfor it.\n"},{"id":"472802","messageId":"87pm9v6n9a.fsf@osv.gnss.ru","threadId":"59200","inReplyTo":"CABPp-BGJ+jdwizBNyYr-st58F6BPbyrJ+DwRX81_0NjgU6LhzA@mail.gmail.com","subject":"Re: [PATCH] pull: conflict hint pull.rebase suggestion should offer \"merges\" vs \"true\"","fromName":"Sergey Organov","fromEmail":"sorganov@gmail.com","sentAt":"2023-02-27T17:17:53Z","receivedAt":"2023-02-27T17:18:03Z","isPatch":true,"sender":{"key":"sorganov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8501568?v=4"},"body":"Elijah Newren writes:\n\n> On Sun, Feb 26, 2023 at 1:29 AM Sergey Organov wrote:\n>>\n>> Elijah Newren writes:\n>>\n>> > On Sat, Feb 25, 2023 at 7:15 AM Sergey Organov wrote:\n>> >>\n>> >> Elijah Newren writes:\n>> >>\n>> >> > On Fri, Feb 24, 2023 at 2:06 PM Sergey Organov wrote:\n>> >> >>\n>> >> >> Elijah Newren writes:\n>> >>\n>> >> [...]\n>> >>\n>> >> > Please, go read at least [1] to see Johannes comments about how the\n>> >> > prior proposals don't work beyond simple cases.\n>> >>\n>> >> It's exactly handling of simple cases that we need most. We can get\n>> >> fancy afterwards, if feasible.\n>> >\n>> > If we can handle just the simple cases without making common cases\n>> > significantly worse, that'd be a potential path forward. Any proposal\n>> > involving the diff between a merge commit and either of its parents\n>> > (or an equivalent such as a three-way merge involving the merge commit\n>> > and one of its parents) doesn't achieve that, IMO.\n>>\n>> Except the method discussed does achieve exactly that according to the\n>> evidence gathered at the time of debates, and here is confirmation (from\n>> Johannes himself) from the reference you provided:\n>\n> I'm glad you read it. :-)\n\nIn fact I didn't read it, I rather re-read it ;-)\n\n(I'm in the CC list there, so it should not have been a surprise I did\nread it then.)\n\n>\n>> \"This strategy, while it performed well in my initial tests (and in\n>> Buga's initial tests, too), *does* involve more than one 3-way merge,\n>> and therefore it risks something very, very nasty: *nested* merge\n>> conflicts.\"\n>>\n>> So, overall, the method performs well in general,\n>\n> Jumping from \"performed well on initial tests\" to \"performs well in\n> general\" seems to me to be quite a large and unwarranted logical leap.\n\nThere were quite a few tests performed and methods were polished before\nJohannes has been persuaded to give the feature a try, some of the tests\nbeing complex enough, and both methods did perform rather well. That is\nwhat he calls \"initial tests\" there I believe, and then he found the\ncase that is very important to him, but lead him to nested merge\nconflicts, that is indeed quite bad.\n\n>\n>> and we just need to avoid driving ourselves into nested merge\n>> conflicts\n>\n> I'm glad you're discussing a disadvantage and how to address it, but I\n> don't understand how you can jump to the implication that this is the\n> only one.\n\nWell, it was you who gave me the reference to comment on, and that was\nthe only disadvantage I was able to find being discussed there. I also\ndon't recall any other objections back then when the problem has been\ndiscussed a lot.\n\n>> Setting this back into perspective, in comparison to blind re-merge,\n>> that fails to keep user changes even when no conflicts at all exist, and\n>> even when it's applied at the same place in the history, the discussed\n>> method is a *huge* step forward, especially if re-merge is kept as a\n>> fallback strategy.\n>\n> The use of superlatives and asterisks doesn't change my opinion; I'm\n> still skeptical that the given strategy is overall a step forward, let\n> alone a large one.\n\nYou just repeat saying the same thing, without any further arguments?\nOK, thank you for your opinion anyway.\n\n> (I do agree we have a huge problem and thus that a huge step forward\n> theoretically could be taken, I just don't see this as it.)\n\nIt works. Really.\n\n>\n>> P.S. BTW, where this hate for using of diffs with respect to parents\n>> come from, I wonder, provided we do use them all the time anyway?\n>\n> I have no hate for such diffs; I just firmly believe they are\n> inappropriate as a solution for the particular problem space being\n> discussed.\n\nFrom my POV particular problem space (rebasing commits) already uses the\ndiffs, and only them, that's why I can't figure how you end up coming to\nsuch conclusion.\n\n>\n> But I've stated that more than enough, and no one is producing patches\n> on this topic right now, so I'll drop out of this thread.\n\nOK, I participate only in hope that there will be somebody who actually\ncares enough to implement it. Maybe it will be me, maybe not, and I\nalready got it that neither you nor the original author of git-rebase\nare interested.\n\n> I still believe in my proposed solution, and I'll implement it as I\n> get time for it.\n\nSure it'd be nice. Fortunately there is nothing mutually exclusive here.\n\nThanks,\n-- Sergey Organov\n"},{"id":"472838","messageId":"CABPp-BHVLx+wikxsJqDjFM416PoC6CY-5L7RQDqJAdU7kOeDyA@mail.gmail.com","threadId":"59200","inReplyTo":"87pm9v6n9a.fsf@osv.gnss.ru","subject":"Re: [PATCH] pull: conflict hint pull.rebase suggestion should offer \"merges\" vs \"true\"","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2023-02-28T02:35:00Z","receivedAt":"2023-02-28T02:35:10Z","isPatch":true,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"Note: I'm not talking about rebasing merges anymore in this thread,\nbut I thought there was a useful how-we're-communicating subthread\nthat's worth addressing to see if we can make that part work better...\n\nOn Mon, Feb 27, 2023 at 9:17 AM Sergey Organov wrote:\n>\n> Elijah Newren writes:\n>\n> > On Sun, Feb 26, 2023 at 1:29 AM Sergey Organov wrote:\n> >>\n> >> Elijah Newren writes:\n> >>\n> >> > On Sat, Feb 25, 2023 at 7:15 AM Sergey Organov wrote:\n> >> >>\n> >> >> Elijah Newren writes:\n> >> >>\n> >> >> > On Fri, Feb 24, 2023 at 2:06 PM Sergey Organov wrote:\n> >> >> >>\n> >> >> >> Elijah Newren writes:\n> >> >>\n> >> >> [...]\n> >> >>\n> >> >> > Please, go read at least [1] to see Johannes comments about how the\n> >> >> > prior proposals don't work beyond simple cases.\n[...]\n> >> Except the method discussed does achieve exactly that according to the\n> >> evidence gathered at the time of debates, and here is confirmation (from\n> >> Johannes himself) from the reference you provided:\n> >\n> > I'm glad you read it. :-)\n>\n> In fact I didn't read it, I rather re-read it ;-)\n>\n> (I'm in the CC list there, so it should not have been a surprise I did\n> read it then.)\n\nI knew you were on the CC, I just didn't believe at the time that you\ncould have read that email and still claimed that \"As for Dscho\nresults specifically, I've got an impression that he never\nneeded rebasing of merges in the first place\", so I assumed you had\nskipped that email or only lightly skimmed it.\n\nI'm still quite surprised, but clearly my assumption that you read the\nemail was wrong. Sorry about that.\n\n> >> Setting this back into perspective, in comparison to blind re-merge,\n> >> that fails to keep user changes even when no conflicts at all exist, and\n> >> even when it's applied at the same place in the history, the discussed\n> >> method is a *huge* step forward, especially if re-merge is kept as a\n> >> fallback strategy.\n> >\n> > The use of superlatives and asterisks doesn't change my opinion; I'm\n> > still skeptical that the given strategy is overall a step forward, let\n> > alone a large one.\n>\n> You just repeat saying the same thing, without any further arguments?\n> OK, thank you for your opinion anyway.\n\nThat exactly mirrors how I've felt about your emails in this thread.\nYou are right that I'm not going into detail either...but why would I?\n\n * I'm not trying to convince you to implement these ideas or change\nyour own implementation, especially since:\n * You've previously said you aren't even planning on working on this[1].\n\nOf course, you can easily ask why I would think you might provide\ndetails when I was not providing any. Well, from my viewpoint:\n\n * You did say you were hoping someone else would work on this\nproblem[1,2,& end of this email], and I've expressed interest in\nworking on the problem space.\n * If you want someone to work on your ideas, using your particular\nfavored approach, for free, then you need to convince them that your\napproach is worth investing in\n * I have read the old proposals, in detail, and stated I don't\nbelieve in them.\n * You didn't try to address my concerns beyond simply reasserting\nthat the ideas in the original proposals were good, and seemed to be\nmore interested in discrediting or minimizing my concerns (e.g. asking\nwhy I \"hated diffs from merge to either parent\") than in learning\nabout or addressing them.\n\nI think your intentions are good (you're trying to solve a big problem\nin Git), I'm just a little worried about the execution (e.g. brushing\naside my concerns so folks won't pay attention to them while actively\nrecruiting eager contributors, with the plan to send them down what I\nbelieve is a dead-end path). If it was just you going down this path,\nI wouldn't be so concerned. Personally, I pursue a *lot* of my own\nbad ideas, and learn in the process that they were bad. Also, if you\nshowed some willingness to entertain that I might be right that the\nold proposals are bad, and could communicate that to new contributors\nand let them decide, I would have dropped out of the thread sooner and\njust let you do your thing.\n\nThe way you've responded in this thread doesn't seem unique to our\ninteractions; it reminds me of an interaction you had with Junio at\n[3]. He suggested there were some code issues. You could have asked\nwhat they were and maybe learned how to improve things. Or maybe you\ncould have learned that he just had a specific misunderstanding which\ncould have been corrected if you asked some questions to find out what\nhe was thinking. Instead, you simply asserted that things were fine\nand dismissed his concerns. I think it was a lost opportunity.\n\nNow, it's fully possible here that I've misunderstood your purpose; if\nso, I apologize. The above was the understanding I was working off\nof; maybe knowing that will help you understand my responses.\n\n[1] stated in final paragraph of\nhttps://lore.kernel.org/git/87zgkh9buq.fsf@osv.gnss.ru/\n[2] hinted at in final paragraph of\nhttps://lore.kernel.org/git/87bklilnvp.fsf@osv.gnss.ru/\n[3] https://lore.kernel.org/git/87wna3jwx8.fsf@osv.gnss.ru/\n\n> > (I do agree we have a huge problem and thus that a huge step forward\n> > theoretically could be taken, I just don't see this as it.)\n>\n> It works. Really.\n>\n\n> > But I've stated that more than enough, and no one is producing patches\n> > on this topic right now, so I'll drop out of this thread.\n>\n> OK, I participate only in hope that there will be somebody who actually\n> cares enough to implement it. Maybe it will be me, maybe not, and I\n> already got it that neither you nor the original author of git-rebase\n> are interested.\n\nCorrect, I'm not interested in implementing it that particular way,\nthough I will be implementing it in what I feel is the right way.\n\nAnyway, I hope something I said above helps in some way. Even if not,\nI wish you the best of luck on your efforts.\n"},{"id":"472846","messageId":"CAMP44s1_Oy8GzoALnvQMJEVRkDB3EBmn4drTyY6T+9BatRpjUA@mail.gmail.com","threadId":"59200","inReplyTo":"CAPMMpogFAR6cvcR8T5fx+AoytAJ7TsPpSeOjHNzW4Gmkuq7FLQ@mail.gmail.com","subject":"Re: [PATCH] pull: conflict hint pull.rebase suggestion should offer \"merges\" vs \"true\"","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2023-02-28T14:13:14Z","receivedAt":"2023-02-28T14:13:31Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Feb 16, 2023 at 7:33 AM Tao Klerks wrote:\n> On Thu, Feb 16, 2023 at 4:22 AM Alex Henrie wrote:\n\n> > Now, this is not to say that there's no room for improvement. I like\n> > the rebase=merges option and I wish everyone knew about it because\n> > there are situations where it really is the best option. I suggest\n> > leaving the existing text alone, but adding an additional paragraph,\n> > something like:\n> >\n> > Note that --rebase or pull.rebase=true will drop existing merge\n> > commits and rebase all of the commits from all of the merged branches.\n> > If you want to rebase but preserve existing merge commits, use\n> > --rebase=merges or pull.rebase=merges instead.\n>\n> My primary motivation with this pull request is to reduce the\n> incidences, out there in the world, of people copy-pasting \"git config\n> pull.rebase true\" into their command-line, and causing themselves\n> major headaches days or weeks later. The \"--rebase=interactive\" part\n> is secondary (to my concerns), because it's much less copy-pastable.\n\nThat's because the whole approach to the pull.rebase configuration is\nwrong. I explained why multiple times in countless discussions and git\ndevelopers did not listen.\n\nWhat we need is a pull.mode configuration that is *orthogonal* to\npull.rebase, then everything just works.\n\nFor example, you could have this configuration.\n\n git config pull.mode merge\n git config pull.rebase merges\n\nThen doing `git pull --rebase` would do a merges rebase.\n\nThis is not possible with the current approach, which I objected to.\n\nThen there's no problem with telling the users to do pull.mode=rebase\n(or whatever), since that doesn't override pull.rebase=merges.\n\nI programmed and explained this precise interaction with rebase=merges\nmore than two years ago [1], but nobody listened. For an example of\nhow such configuration would look like, see the patches I just sent\n[2].\n\nCheers.\n\n[1] https://lore.kernel.org/git/20201218211026.1937168-14-felipe.contreras@gmail.com/\n[2] https://lore.kernel.org/git/20230228140236.4175835-1-felipe.contreras@gmail.com/T/#t\n\n-- \nFelipe Contreras\n"},{"id":"472860","messageId":"CAMMLpeRCKMqVNYvL9i0HGTEKvaACaEyCWCotzKfo-OQW2y_BpQ@mail.gmail.com","threadId":"59200","inReplyTo":"CAMP44s1_Oy8GzoALnvQMJEVRkDB3EBmn4drTyY6T+9BatRpjUA@mail.gmail.com","subject":"Re: [PATCH] pull: conflict hint pull.rebase suggestion should offer \"merges\" vs \"true\"","fromName":"Alex Henrie","fromEmail":"alexhenrie24@gmail.com","sentAt":"2023-02-28T20:04:19Z","receivedAt":"2023-02-28T20:04:46Z","isPatch":true,"sender":{"key":"alexhenrie24@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5951993?v=4"},"body":"On Tue, Feb 28, 2023 at 7:13 AM Felipe Contreras\n wrote:\n>\n> On Thu, Feb 16, 2023 at 7:33 AM Tao Klerks wrote:\n> > On Thu, Feb 16, 2023 at 4:22 AM Alex Henrie wrote:\n>\n> > > Now, this is not to say that there's no room for improvement. I like\n> > > the rebase=merges option and I wish everyone knew about it because\n> > > there are situations where it really is the best option. I suggest\n> > > leaving the existing text alone, but adding an additional paragraph,\n> > > something like:\n> > >\n> > > Note that --rebase or pull.rebase=true will drop existing merge\n> > > commits and rebase all of the commits from all of the merged branches.\n> > > If you want to rebase but preserve existing merge commits, use\n> > > --rebase=merges or pull.rebase=merges instead.\n> >\n> > My primary motivation with this pull request is to reduce the\n> > incidences, out there in the world, of people copy-pasting \"git config\n> > pull.rebase true\" into their command-line, and causing themselves\n> > major headaches days or weeks later. The \"--rebase=interactive\" part\n> > is secondary (to my concerns), because it's much less copy-pastable.\n>\n> That's because the whole approach to the pull.rebase configuration is\n> wrong. I explained why multiple times in countless discussions and git\n> developers did not listen.\n>\n> What we need is a pull.mode configuration that is *orthogonal* to\n> pull.rebase, then everything just works.\n>\n> For example, you could have this configuration.\n>\n> git config pull.mode merge\n> git config pull.rebase merges\n>\n> Then doing `git pull --rebase` would do a merges rebase.\n>\n> This is not possible with the current approach, which I objected to.\n>\n> Then there's no problem with telling the users to do pull.mode=rebase\n> (or whatever), since that doesn't override pull.rebase=merges.\n>\n> I programmed and explained this precise interaction with rebase=merges\n> more than two years ago [1], but nobody listened. For an example of\n> how such configuration would look like, see the patches I just sent\n> [2].\n>\n> Cheers.\n>\n> [1] https://lore.kernel.org/git/20201218211026.1937168-14-felipe.contreras@gmail.com/\n> [2] https://lore.kernel.org/git/20230228140236.4175835-1-felipe.contreras@gmail.com/T/#t\n\nI think everybody agrees that the current situation is kind of a mess.\nFor better or for worse, there was no consensus to get away from the\ncurrent set of config options and introduce something more\nstraightforward, so we keep making incremental evolutionary changes\nwithin the current framework.\n\nI didn't include it in my list of things to do, but your email made me\nrealize that the problem with `git pull` not being able to do an\ninteractive rebase that rebases merge commits is also something that\nneeds to be fixed before flipping on \"rebase merges\" by default. If we\nadd that to the list, I guess it would be step 2.25. It's going to be\nconfusing if `git pull -r` rebases merges but `git pull -ri` does not.\nOne way to solve that would be to make -ri/--rebase=interactive on the\ncommand line work with pull.rebase=merges instead of overriding it,\nand add a separate --(no-)rebase-merges command line option for if the\nuser really does want to override it.\n\nOn top of that, either before or at the same time as when the default\nbehavior of `git pull --rebase` changes to rebase merges, the behavior\nof branch.autoSetupRebase needs to change to match.\n\n-Alex\n"},{"id":"472888","messageId":"CAMP44s3XS=43ZWF6MaLHvhf_VMuJKog8T46tHsmypu-xcMAw-Q@mail.gmail.com","threadId":"59200","inReplyTo":"CAMMLpeRCKMqVNYvL9i0HGTEKvaACaEyCWCotzKfo-OQW2y_BpQ@mail.gmail.com","subject":"Re: [PATCH] pull: conflict hint pull.rebase suggestion should offer \"merges\" vs \"true\"","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2023-03-01T12:46:32Z","receivedAt":"2023-03-01T12:46:51Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, Feb 28, 2023 at 2:04 PM Alex Henrie wrote:\n\n> I think everybody agrees that the current situation is kind of a mess.\n> For better or for worse, there was no consensus to get away from the\n> current set of config options and introduce something more\n> straightforward, so we keep making incremental evolutionary changes\n> within the current framework.\n\nYes, but my proposed incremental evolutionary changes would have\nsolved the problems by now if the maintainer club bothered to look at\nthem.\n\nInstead, they implemented a solution from one of their club, which in\nmy opinion is an incremental change that made the situation *worse*,\nnot better.\n\nThis issue with pull.rebase=merges is one that I had *already*\nexplained to them, and they ignored it. And it's not the only one.\n\nWhen you ignore the opinions of certain kinds of people, and only\nlisten to certain kinds of people, you end up with worse code.\n\nCheers.\n\n-- \nFelipe Contreras\n"}]}