[UX] Incorrect use of "Fetch" terminology in branch context menu

[timolex]

Current Behavior

In the UI, when right-clicking on a local branch to perform an action to integrate a remote-tracking branch into a local branch, the corresponding label reads something like:
Fetch origin/master into master:

However, under the hood, this action executes a git fetch followed by git pull or git merge, which absolutely alters the local working branch.

Why This Is an Issue

In Git terminology, fetch is strictly a safe, non-destructive operation. A standard git fetch updates local remote-tracking branches (like origin/master) but never touches or modifies local working branches (like master).

Using the phrase "Fetch [remote] into [local]" is technically inaccurate and creates UX confusion. A user expecting a harmless background fetch might accidentally trigger an unintended merge, potentially leading to unexpected merge conflicts in their active workspace.

Suggested Fix

Change the UI text to use accurate Git terminology. Depending on the exact underlying command being executed, consider changing the label to:

• Pull origin/master into master (if it fetches and merges)
• Merge origin/master into master (if it is specifically performing the merge step)

[love-linger]

Fetch <upstream> into <local> runs the following command:

git fetch --progress --verbose <remote> <remote_branch>:<local_branch>

See: https://git-scm.com/docs/git-fetch#_examples

[love-linger]

The difference between Fast-Forward to <upstream> and Fetch <upstream> into <local> is:

Fast-Forward will not fetch changes from remote. It only uses the sate of local repository. While Fetch <upstream> into <local> will fetching the latest changes in remote branch and update the local branch with the fetched upstream.

[love-linger]

We can not rename it to Pull or Merge because both these two command are only used to update CURRENT branch.

Pull or Merge will cause conflicts. So they are only used to update CURRENT branch. Otherwise, git does not know where to place the conflicted files.

[love-linger]

And Fetch <upstream> into <local> will only appear in non-current branch when it has no ahead commits comparing to its upstream. We also use <remote>:<local> instead of +<remote>:<local> to prevent local branch being updated when it can not fast-forward to its upstream.

[timolex]

@love-linger I will have to respectfully disagree:

You state: "We can not rename it to Pull or Merge because both these two command are only used to update CURRENT branch."
However, it's clearly specified in the documentation, that git pull will only ever update the current local branch unless the command is run WITH arguments. So it is in fact not true, that git pull would only be applicable to the current branch, but also to different target branches defined in a supplied argument.

That said, I still believe, that even for non-current branches, the menu item should read Pull origin/master into master as git fetch only targets remote-tracking branches:

Definition of remote-tracking branches:

Imho, it should be 100% clear to the user, that the context menu option currently reading Fetch will absolutely change one of their local working branches, as long as the remote had received changes.

[love-linger]

• First, Where did you see that git pull can update non‑current branches? Or provide the corresponding command. If conflicts occur when executing git pull or git merge, are the conflict files placed directly in the current working directory (when you want to merge into non-current branch)?
• Second, this menu actually run git fetch command instead of git pull or git merge. Why do you think using Pull or Merge is better. And git never says git fetch will not update local branches, instead, it just gives user an example to do it.
• What's more, we are not talking about remote branches or upstreams

[love-linger]

Do you mean this?

It just says we can merge other branches instead of the tracking upstream of current branch into CURRENT branch. Not means you can merge branches into non-current branch.

Just like the Pull feature in SourceGit, you can select any remote branch (not only the tracking upstream) into current branch:

[timolex]

Ok fair point, "pull" of course won't really make sense if you want to update some non-current/checked out local branch to the latest available commit on the remote.
However, "fetch" still doesn't make sense to me in this case, because users might associate the term "fetch" with git fetch, which in the Git realm always represents a safe way to track remote changes, i.e., without immediately overwriting any local branches.

=> To avoid this kind of confusion, how about just re-naming said context menu option of local branches to Update?

[love-linger]

I do not know why do you think Fetch <upstream> into <local> is a bad description for git fetch <remote> <remote_branch>:<local_branch> command. I believe the word into clearly indicates that the result of fetch will update the <local> ref

Here is the original feature request: #617

[goran-w]

@timolex - The underlying command is indeed a git fetch, and into in the name maps directly to the colon used in <remote-branch>:<local-branch>. Seems fine to me. 😉 Would you agree to close this issue?