Uploaded image for project: 'Sourcetree For Mac'
  1. Sourcetree For Mac
  2. SRCTREE-2489

Commit: push changes immediately to...picks wrong remote

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Low Low
    • 1.9.5
    • 1.9.4
    • Git
    • None
    • OS X 10.9.3

      So before the revamp of the staging and commit flow, the remote chosen to 'push changes immediately to..' seemed to be either the last remote I committed to or the first remote listed in the git config file.

      Now it seems to get stuck on just the first remote listed in the remotes list on the left panel. There is no way to sort or prioritize the list of remotes in Sourcetree (that I can find) so no way to tell it to always pick 'origin' or something.

      This should either be configurable with some priority or matching rules or just go off the .git/config ordering like I think it used to.

      You can see in the screenshots I attached, mine is stuck on corey/master most likely since the list of remotes is ordered alphabetically and 'corey' is first. You can see that the 'corey' remote is specified much later in the .git/config file and should not be chosen all the time as the remote I would push to normally.

      Thanks!

          Form Name

            [SRCTREE-2489] Commit: push changes immediately to...picks wrong remote

            I didn't even know these settings existed (I'm from the Windows world originally and always forget about the unified Preferences...).

            I set it to 'upstream' and it's working as I would expect now, thanks!

            Nick Fedesna added a comment - I didn't even know these settings existed (I'm from the Windows world originally and always forget about the unified Preferences...). I set it to 'upstream' and it's working as I would expect now, thanks!

            From the next update if push.branch is 'matching' we check origin before other remotes for matches.

            Steve Streeting (Inactive) added a comment - From the next update if push.branch is 'matching' we check origin before other remotes for matches.

            Ah, I know what this is. You must have the Preferences > Git > Push branches option set to 'matching', and what ST does is iterate over the git remotes and uses the first that matches the git rules. Because 'matching' can match any same-named branch on the remote and your remotes are ordered so that corey comes first, git technically says that your local branch matches that and we stop.

            Short term the easy fix is to change the option in Preferences > Git > Push branches to 'upstream' or 'simple'. This means that you by default push to the same branch you'd pull from ('simple' just validates that they're also called the same name). From git version 2.0, 'simple' is the default; it's 'matching' before that.

            Longer term we'll be changing our own default to 'simple' to match git 2.0 but we should also probably check 'origin' before all others to be safer.

            Steve Streeting (Inactive) added a comment - Ah, I know what this is. You must have the Preferences > Git > Push branches option set to 'matching', and what ST does is iterate over the git remotes and uses the first that matches the git rules. Because 'matching' can match any same-named branch on the remote and your remotes are ordered so that corey comes first, git technically says that your local branch matches that and we stop. Short term the easy fix is to change the option in Preferences > Git > Push branches to 'upstream' or 'simple'. This means that you by default push to the same branch you'd pull from ('simple' just validates that they're also called the same name). From git version 2.0, 'simple' is the default; it's 'matching' before that. Longer term we'll be changing our own default to 'simple' to match git 2.0 but we should also probably check 'origin' before all others to be safer.

              Unassigned Unassigned
              nick.fedesna Nick Fedesna
              Affected customers:
              0 This affects my team
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                Resolved: