{"thread":{"id":"57364","subject":"branch.autoSetupMerge option for \"if name matches only\"?","startedAt":"2022-02-03T18:58:30Z","lastAt":"2022-02-24T16:48:01Z","messageCount":3,"participants":["Tao Klerks","Xavier Morel"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"447639","messageId":"CAPMMpog6vKBfYEWqKDgK7YQQ96pPVMH7hYPXUHMnJsgLNgYMXA@mail.gmail.com","threadId":"57364","inReplyTo":null,"subject":"branch.autoSetupMerge option for \"if name matches only\"?","fromName":"Tao Klerks","fromEmail":"tao@klerks.biz","sentAt":"2022-02-03T18:58:15Z","receivedAt":"2022-02-03T18:58:30Z","isPatch":false,"sender":{"key":"tao@klerks.biz","avatar":"https://avatars.githubusercontent.com/u/531704?v=4"},"body":"Hi folks,\n\nIn trying to recommend sane simple understandable git flows for large\nnumbers of (often not git-proficient) users, I've found upstream\ntracking branches to be a sticky area.\n\nThe main problem is that when users intentionally create a new branch\n\"test1\" from origin/master, for example, they automatically get\nupstream tracking... but after they've pushed their new branch to the\nremote, they (unless they do something \"wrong\") typically have\ntracking switched to \"origin/test1\" (after a weird error about not\npushing to a differently-named upstream - because they have\npush.default set to \"simple\", the safe default - unless they're using\na GUI that sweeps this under the rug). So the behavior of \"pull\"\nchanges dramatically, from the user's perspective, after the first\ntime they push. Until that point, the system is behaving \"weird\".\n\nOn the other hand, when another user wants to work on \"test1\"\ndirectly, they branch from \"origin/test1\", they get upstream tracking,\nand everything is normal/predictable.\n\nI *think* the simplest / most understandable behavior for most users\nwould be a variation on the current branch.autoSetupMerge=true\nbehavior, except *only set up tracking if the local branch name\nmatches*.\n\nThis new branch.autoSetupMerge behavior (dare we call it \"simple\", to\nmatch push.default?) would mean that when branching from origin/master\nto test1, you would not get an upstream. Pull would say something like\n\"hey, you haven't pushed yet\", and everything would be understandable.\n\nIs this a scheme that makes sense to people here?\n\nAlternatively, another workable option for my not-so-sophisticated\nusers would be something like branch.autoSetupMerge=current, which\nwould simply always assume the same-name branch on the same remote. If\nthis were a new branch, initial pulls would say \"but there's no such\nbranch on the remote!\", and the first push would be even simpler,\nsucceeding without the current surprising \"The current branch has no\nupstream branch -0 run this slightly-more-complex command\" message.\n\nAre my users the only ones who get caught out by the default tracking\nbehavior when branching from a different upstream branch (but *expect*\ntracking when creating a local instance of a remote branch)?\n\nThanks,\nTao\n"},{"id":"448046","messageId":"b54a6cde-5065-632b-012c-0d6f777249ef@odoo.com","threadId":"57364","inReplyTo":"CAPMMpog6vKBfYEWqKDgK7YQQ96pPVMH7hYPXUHMnJsgLNgYMXA@mail.gmail.com","subject":"Re: branch.autoSetupMerge option for \"if name matches only\"?","fromName":"Xavier Morel","fromEmail":"xmo@odoo.com","sentAt":"2022-02-09T13:46:37Z","receivedAt":"2022-02-09T13:46:31Z","isPatch":false,"sender":{"key":"xmo@odoo.com","avatar":"https://gravatar.com/avatar/42b8eb16dcf3bd6c1998698115b36ab6f4d69f93710caa10ff8ab04a9652ae34?d=mp&s=160"},"body":"I found this message when trying to see if someone had already suggested \nsomething along those lines.\n\nIn fact I would be even more restrictive: what I wanted to propose was \nto only automatically setup the merge on implicit remote tracking \nbranches, that is:\n\n     git switch foo\n\nif there is no such branch locally will look for the corresponding \nbranch in the remotes, and will create a matching local one. In that \ncase it makes a lot of sense to create a remote-tracking branch: when \nimplicitly checking out a remote branch, it's likely the goal is to \ntrack it.\n\nThe issue is that\n\n     git switch -c bar foo\n\nwill do the same, despite explicitely creating a differently named \nbranch, which is probably some sort of feature which needs to be \nremote-ed somewhere else. If this issue is not caught immediately it is \npossible to push directly upstream by mistake.\n\nUpon reading the documentation of `git switch` I actually believed this \nwould behave correctly given `autoSetupMerge=false`:\n\n     --guess, --no-guess\n         If <branch> is not found but there does exist a tracking branch \nin exactly one remote (call it <remote>) with\n         a matching name, treat as equivalent to\n\n             $ git switch -c <branch> --track <remote>/<branch>\n\nBecause `--guess` is the default for the `git switch <name>` form, this \ndescription made me believe the tracking would be forced.\n\nSadly it is not so, setting `autoSetupMerge=false` will also disable \nautomatic remote-tracking on guessed branch.\n\nAs far as I'm concerned, `git switch` actually behaving as documented \nwould resolve the entire issue (especially if it were possible to \ndisable `git checkout` somehow, such that I would have to force muscle \nmemory).\n\nThis is made more annoying because\n\n     git switch -t foo\n\n*does not work*, frustratingly (if as documented, this time) `-t` \nimplies `-c`. So it's not even possible to remember to type `git switch \n-t remotebranch` and then live happily with `autoSetupMerge=false`. This \nmakes `autoSetupMerge=false` a lot more frustrating that necessary.\n"},{"id":"449477","messageId":"CAPMMpojn9uYEuG07ky6Jz-F4PAGRjY8Y_az2EbM1cvq98QBnwQ@mail.gmail.com","threadId":"57364","inReplyTo":"b54a6cde-5065-632b-012c-0d6f777249ef@odoo.com","subject":"Re: branch.autoSetupMerge option for \"if name matches only\"?","fromName":"Tao Klerks","fromEmail":"tao@klerks.biz","sentAt":"2022-02-24T16:47:46Z","receivedAt":"2022-02-24T16:48:01Z","isPatch":false,"sender":{"key":"tao@klerks.biz","avatar":"https://avatars.githubusercontent.com/u/531704?v=4"},"body":"Hi Xavier,\n\nThanks for the follow-up.\n\n>I found this message when trying to see if someone had already suggested\n> something along those lines.\n\nDid you find any other related threads that could add context? I did\nnot find anything when I looked.\n\n> what I wanted to propose was to only automatically setup the merge on\n> implicit remote tracking branches\n\nWhile I understand this as a personal expectation/preference, that\ndoesn't seem to align with the expectations of the \"beginner users\"\nthat I interact with;\n\ngenerally, they expect a branch that is \"the local version of a remote\nbranch\" to behave one way, and a branch that \"was 'branched' from the\nthen-HEAD of a remote branch\" to behave another way - regardless of\nwhether a given user knows the \"pretend I already have the branch\nlocally / create it on-the-fly\" syntax, or is explicit about saying \"I\nwant to work on (for example) master which I know is origin/master on\nthe remote\".\n\n> As far as I'm concerned, `git switch` actually behaving as documented\n> would resolve the entire issue\n\nI'm not sure I understand this. I just tested and got exactly what I\nexpected from the doc:\n\n$ git -c merge.autosetupmerge=false switch -t origin/mybranch\nBranch 'mybranch' set up to track remote branch 'mybranch' from 'origin'.\nSwitched to a new branch 'mybranch'\n\nI agree being able to say \"git switch mybranch\", without the other\nside effects of merge.autosetupmerge=true, would be convenient... but\nthen I'm arguing for a broader change and (in my opinion) better value\nof \"merge.autosetupmerge\" altogether :)\n\nFwiw, I submitted a patch introducing this\n\"merge.autosetupmerge=simple\" option earlier today, but no reactions\nyet. I don't know whether that's because project members disagree that\nthere is inherent unnecessary complexity facing \"beginners\" in the\ncurrent behavior, or disagree that this is a reasonable direction to\nreduce that complexity, or are frustrated with my spotty participation\nrecord in this mailing list, or the terrible quality of my C- and\nproject-novice code, or simply haven't looked at this topic yet!\n\nThe patch series is titled \"adding new branch.autosetupmerge option \"simple\"\".\n\nThanks again,\nTao\n\n\nOn Wed, Feb 9, 2022 at 2:46 PM Xavier Morel <xmo@odoo.com> wrote:\n>\n> I found this message when trying to see if someone had already suggested\n> something along those lines.\n>\n> In fact I would be even more restrictive: what I wanted to propose was\n> to only automatically setup the merge on implicit remote tracking\n> branches, that is:\n>\n>      git switch foo\n>\n> if there is no such branch locally will look for the corresponding\n> branch in the remotes, and will create a matching local one. In that\n> case it makes a lot of sense to create a remote-tracking branch: when\n> implicitly checking out a remote branch, it's likely the goal is to\n> track it.\n>\n> The issue is that\n>\n>      git switch -c bar foo\n>\n> will do the same, despite explicitely creating a differently named\n> branch, which is probably some sort of feature which needs to be\n> remote-ed somewhere else. If this issue is not caught immediately it is\n> possible to push directly upstream by mistake.\n>\n> Upon reading the documentation of `git switch` I actually believed this\n> would behave correctly given `autoSetupMerge=false`:\n>\n>      --guess, --no-guess\n>          If <branch> is not found but there does exist a tracking branch\n> in exactly one remote (call it <remote>) with\n>          a matching name, treat as equivalent to\n>\n>              $ git switch -c <branch> --track <remote>/<branch>\n>\n> Because `--guess` is the default for the `git switch <name>` form, this\n> description made me believe the tracking would be forced.\n>\n> Sadly it is not so, setting `autoSetupMerge=false` will also disable\n> automatic remote-tracking on guessed branch.\n>\n> As far as I'm concerned, `git switch` actually behaving as documented\n> would resolve the entire issue (especially if it were possible to\n> disable `git checkout` somehow, such that I would have to force muscle\n> memory).\n>\n> This is made more annoying because\n>\n>      git switch -t foo\n>\n> *does not work*, frustratingly (if as documented, this time) `-t`\n> implies `-c`. So it's not even possible to remember to type `git switch\n> -t remotebranch` and then live happily with `autoSetupMerge=false`. This\n> makes `autoSetupMerge=false` a lot more frustrating that necessary.\n"}]}