When using mirror repository, Application expects repos to be identical

Description

When remotes differ and (1) repo contains unmirrored commits or (2) current branch is not mirrored. “Sync/Fetch/Publish button” displays “Publish branch/repository” even if commits/branch has been just been pushed successfully.

Version

GitHub Desktop version: 1.0.12

OS version: Win 10

Steps to Reproduce

1. Clone public repo. _Example: https://github.com/desktop/desktop.git_
2. Set push remote to a mirror repository. Example: $ git remote set-url --push origin https://github.com/oiyouyeahyou/desktop.git
3. Create branch new branch
4. Click “Sync” button
5. Observe changes should be on “push” mirror repo. Yet application still believes the branch needs to be published

Expected behaviour: Application recognises when split remotes are being used

Actual behaviour: Application does not register that changes are not symmetrical between mirror repos

Reproduces how often: 100%

<small>Sorry for inelegant Title</small>

[shiftkey]

I can share a bit more about the root problem here, but I’m not sure if this is something we can fix.

Here’s my fork setup with the split fetch and push URLs on the single remote:

$ git remote -v
origin	https://github.com/desktop/desktop.git (fetch)
origin	https://github.com/shiftkey/desktop.git (push)

When I push the new branch in Desktop, it passes --set-upstream and completes without error:

info: [ui] Executing push: git -c credential.helper= push origin testing-push-remote --set-upstream --progress (took 3.412s)

But if you do a git status again you’ll see this message:

$ git status
On branch testing-push-remote
Your branch is based on 'origin/testing-push-remote', but the upstream is gone.
  (use "git branch --unset-upstream" to fixup)

nothing to commit, working tree clean

And while this doesn’t sound right, we can ask git what branches it can see:

$ git branch --all | grep testing
* testing-push-remote

It only has the current branch in it’s list, without the remote ref associated with it.

This is the core of the problem - by using a different push URL for a remote, the operations that use the fetch URL of a remote will no longer see these refs.

I can run ls-remote and confirm this suspicion:

$ git ls-remote --heads
From https://github.com/desktop/desktop.git
95145b57cead3082a1fd98bc36eed0442cb083c2	refs/heads/4k
...
76f90df0ca0f72e7fcabf363f286c40e450c5215	refs/heads/submodule-diff-on-top-of-diff-changes
d674028e75d41d81a3b24c949e03e61525c3535c	refs/heads/tierninho-quality
f47b7c95bb0b80ab6bfa741d230f8a145cbd1694	refs/heads/track-enterprise-version
fe520f8742cc3db06bdcf189389fced8fed2ab66	refs/heads/undo-discard-changes
763fc0e179513c4cc211dd1214ae24c408e592f1	refs/heads/up-is-not-down

Note the first line of the output - it’s using the fetch URL for the origin remote for this operation, which doesn’t contain the ref.

Let’s see if @OiYouYeahYou can share some more information about their use case, and maybe there’s a different way for us to address this in the app.

[shiftkey]

Closing due to inactivity. @OiYouYeahYou if you can provide some more context on your use case we can discuss this further.