fix: fetch before merging in Update from Default Branch

[guplem]

Summary

Closes #110

• Adds await this.props.dispatcher.fetch(repository, FetchType.UserInitiatedTask) before the mergeBranch call in updateBranchWithContributionTargetBranch().
• Makes the method async to allow awaiting the fetch.
• FetchType was already imported; no additional imports needed.

Root cause

updateBranchWithContributionTargetBranch() merged directly against the local ref for the default branch without fetching from remote first. If the local ref was stale, git would correctly report "already up to date" relative to the cached local state — even though the remote had new commits.

Test plan

• Click Branch > Update from Main when the remote default branch has unpulled commits — confirm the fetch runs and the merge succeeds.
• Click Branch > Update from Main when the branch is genuinely up to date — confirm the app correctly reports "already up to date".

[guplem]

Additional context

This is a known issue in the upstream desktop/desktop repo: desktop/desktop#19559 — filed November 2024, still open. Multiple users describe the identical workaround (switch to main → fetch → switch back → "Update from Main").

A GitHub Desktop team member responded saying the behavior is intentional and pointed users to the manual Fetch button. The community is unhappy with that answer, with comments as recent as January 2026 still expressing frustration.

Why silently fetch (no popup)

The action is named "Update from Main" — the implicit contract is "give me the latest from main", which requires a fetch. The mental model doesn't include "...but only if I've already fetched recently". Adding a confirmation dialog or a "fetch + update" / "update only" split would add friction to every use of a very common action, for the benefit of a narrow edge case (offline, metered connection). Background fetch already runs silently — this should be consistent with that.

If the fetch fails, _fetch surfaces the error through the existing error path. No extra dialog needed.

[ignatremizov]

this is big, too many times I merged into a stale main/develop branch - one note shouldn't it also pull fast-forward? because fetch updates origin/main, not necessarily also local main

[pol-rivero]

@guplem That's a nice and clean fix, thanks!

@ignatremizov

one note shouldn't it also pull fast-forward?

Yeah, I was thinking the same thing but then saw that performFetch also calls fastForwardBranches for some reason. This comes from upstream, so I'm not going to touch it, but naming this method "fetch" isn't great.

[guplem]

I actually didn't realize the fast-forward was being done inside the fetch. I actually lean towards not liking it (I didn't think local files/branches should be altered without user intent) but I can live with that

[pol-rivero]

@guplem A possible alternative would be to merge the remote branch (for example origin/main) instead of the local (e.g. main) branch after fetching (without pulling). This would avoid altering the local main branch.
If that's easy to do, feel free to write a follow-up PR, I think that would be an improvement.

[ignatremizov]

@pol-rivero that would create a new branch, origin/main is the "branch on origin", when merging you always merge "locally" then push to a remote branch on origin.

What I think should be instead is a configuration toggle - when "merging to main" - to 1. auto-fetch-fast-forward-pull (default, current behaviour, clean history), or 2. merge-then-fetch-and-pull (would cause an additional merge commit "merge main to origin/main" when pushing to origin/main - looks off but might be someone's workflow for making PRs to an upstream project from a local main branch, for example)

EDIT: Ignore me, see discussion below

[pol-rivero]

@ignatremizov

that would create a new branch, origin/main is the "branch on origin", when merging you always merge "locally" then push to a remote branch on origin.

I'm not sure if I follow. You can absolutely do git merge origin/main without creating a local branch.

[pol-rivero]

Here's what I meant:

2026-03-28.12-47-14.mp4

[ignatremizov]

Right - sorry, I was mixed up for a second about direction. git merge merges the commits pointed to by origin/main into the currently checked out branch, not the other way

Ok, so if the goal is to "Update from Main" meaning the remote main, I propose to change the label to do "Update from Origin Main" (or from whatever remote is configured) so that it's the actual git merge origin/main and not fetch, pull fast forward main, git merge main - this would be better than implicitly fast-forwarding main as part of a routine branch task

[pol-rivero]

Exactly. The only note I would add is that the git fetch is still required to make sure the origin/main pointer is up-to-date. The only difference vs. what we currently have in this PR is that we would not fast-forward the local main branch.

[guplem]

Follow-up PR implementing the improvement suggested by @pol-rivero: #113

It merges origin/main (the remote tracking branch) directly instead of the local main, and fetches without fast-forwarding local branches. The menu label is also updated to show the remote ref (e.g. "Update from origin/main").