Re: branch.autoSetupMerge option for "if name matches only"?

From: Tao Klerks <tao@klerks.biz>
Date: Feb 24, 2022, 16:47 UTC
Message-ID: <CAPMMpojn9uYEuG07ky6Jz-F4PAGRjY8Y_az2EbM1cvq98QBnwQ@mail.gmail.com>
In-Reply-To: <b54a6cde-5065-632b-012c-0d6f777249ef@odoo.com>

Hi Xavier,

Thanks for the follow-up.

>I found this message when trying to see if someone had already suggested
> something along those lines.

Did you find any other related threads that could add context? I did not find anything when I looked.

> what I wanted to propose was to only automatically setup the merge on
> implicit remote tracking branches

While I understand this as a personal expectation/preference, that doesn't seem to align with the expectations of the "beginner users" that I interact with;

generally, they expect a branch that is "the local version of a remote branch" to behave one way, and a branch that "was 'branched' from the then-HEAD of a remote branch" to behave another way - regardless of whether a given user knows the "pretend I already have the branch locally / create it on-the-fly" syntax, or is explicit about saying "I want to work on (for example) master which I know is origin/master on the remote".

> As far as I'm concerned, `git switch` actually behaving as documented
> would resolve the entire issue

I'm not sure I understand this. I just tested and got exactly what I expected from the doc:

$ git -c merge.autosetupmerge=false switch -t origin/mybranch Branch 'mybranch' set up to track remote branch 'mybranch' from 'origin'. Switched to a new branch 'mybranch'

I agree being able to say "git switch mybranch", without the other side effects of merge.autosetupmerge=true, would be convenient... but then I'm arguing for a broader change and (in my opinion) better value of "merge.autosetupmerge" altogether :)

Fwiw, I submitted a patch introducing this "merge.autosetupmerge=simple" option earlier today, but no reactions yet. I don't know whether that's because project members disagree that there is inherent unnecessary complexity facing "beginners" in the current behavior, or disagree that this is a reasonable direction to reduce that complexity, or are frustrated with my spotty participation record in this mailing list, or the terrible quality of my C- and project-novice code, or simply haven't looked at this topic yet!

The patch series is titled "adding new branch.autosetupmerge option "simple"".

Thanks again, Tao

On Wed, Feb 9, 2022 at 2:46 PM Xavier Morel <xmo@odoo.com> wrote:

Show 54 quoted lines

>
> I found this message when trying to see if someone had already suggested
> something along those lines.
>
> In fact I would be even more restrictive: what I wanted to propose was
> to only automatically setup the merge on implicit remote tracking
> branches, that is:
>
>      git switch foo
>
> if there is no such branch locally will look for the corresponding
> branch in the remotes, and will create a matching local one. In that
> case it makes a lot of sense to create a remote-tracking branch: when
> implicitly checking out a remote branch, it's likely the goal is to
> track it.
>
> The issue is that
>
>      git switch -c bar foo
>
> will do the same, despite explicitely creating a differently named
> branch, which is probably some sort of feature which needs to be
> remote-ed somewhere else. If this issue is not caught immediately it is
> possible to push directly upstream by mistake.
>
> Upon reading the documentation of `git switch` I actually believed this
> would behave correctly given `autoSetupMerge=false`:
>
>      --guess, --no-guess
>          If <branch> is not found but there does exist a tracking branch
> in exactly one remote (call it <remote>) with
>          a matching name, treat as equivalent to
>
>              $ git switch -c <branch> --track <remote>/<branch>
>
> Because `--guess` is the default for the `git switch <name>` form, this
> description made me believe the tracking would be forced.
>
> Sadly it is not so, setting `autoSetupMerge=false` will also disable
> automatic remote-tracking on guessed branch.
>
> As far as I'm concerned, `git switch` actually behaving as documented
> would resolve the entire issue (especially if it were possible to
> disable `git checkout` somehow, such that I would have to force muscle
> memory).
>
> This is made more annoying because
>
>      git switch -t foo
>
> *does not work*, frustratingly (if as documented, this time) `-t`
> implies `-c`. So it's not even possible to remember to type `git switch
> -t remotebranch` and then live happily with `autoSetupMerge=false`. This
> makes `autoSetupMerge=false` a lot more frustrating that necessary.