In Git, what does branch.autoSetupMerge control when you create a new branch?

## The problem it solves Creating a branch is a local, cheap operation, but a branch is much more useful once Git knows which remote branch it corresponds to: bare `git push` and `git pull` work, `git status` reports ahead/behind, and `@{u}` resolves. `branch.autoSetupMerge` is the policy knob for *when Git guesses that for you* instead of making you pass `-u` or `git branch -u`. ## The values - **`true`** (default) — configure the upstream when the branch's **start point is a remote-tracking branch**. `git switch -c feature origin/feature` therefore sets `branch.feature.remote = origin` and `branch.feature.merge = refs/heads/feature`. Branching from a local branch sets nothing. - **`false`** — never configure an upstream automatically. Every branch starts unlinked, and a bare `git push` on it fails with "The current branch has no upstream branch" until you set one explicitly. - **`always`** — also configure it when the start point is a **local** branch, in which case the new branch tracks that local branch. Ahead/behind then compares against a local ref, which some people like for stacked branches and others find confusing. Newer Git versions accept further values that refine the behaviour; if you are not certain which your installation supports, `git help config` on the running version is the authority. ## The DWIM checkout A closely related convenience: `git switch feature` (or `git checkout feature`) with no local branch of that name will, when exactly **one** remote has `feature`, create a local branch from `origin/feature` and set the upstream. That behaviour is part of the same auto-setup machinery and is disabled by `--no-guess` on `git switch`. When several remotes carry the same branch name the guess is ambiguous and fails; `checkout.defaultRemote` names which remote wins in that situation. ## Per-command overrides Configuration is the default; flags decide individual cases. - `--track` (`-t`) forces upstream configuration even from a local start point. - `--no-track` suppresses it even from a remote-tracking start point. Both work on `git branch`, `git switch -c`, and `git checkout -b`. `--track` also accepts an explicit form on `git branch` where you name the start point, and `git branch -u` / `--set-upstream-to` remains the way to fix things after the fact. ## The rebase sibling `branch.autoSetupRebase` decides whether Git additionally writes `branch.<name>.rebase = true`, which makes `git pull` on that branch rebase instead of merge. Its values select which kinds of start point trigger it: never (the default), only local branches, only remote-tracking branches, or always. Teams that want rebase-by-default usually reach for the global `pull.rebase` instead, since it applies to existing branches too rather than only newly created ones. ## Why an interviewer asks Mostly to see whether you know that automatic tracking is *policy*, not magic — and that you can turn it off. The practical scenarios are two: someone whose branches never track anything (someone set `false`, or they branch from local `main` under the default) and someone surprised that a branch tracks a local branch (`always` is in effect). Being able to name the config key, its default, and the `--track` / `--no-track` escape hatches is the whole answer. ## Practical guidance Leaving the default alone is right for most teams. If contributors keep hitting the no-upstream error, the modern fix is not `always` — which links branches to local ones — but the newer `push.autoSetupRemote` setting, which makes a branch's first bare push create the remote branch and set its upstream in one step.