Why does the Push button in toolbar open a dialog with EVERY branch preselected instead of the branch i'm on?

[Brian Tully]

Hey there -

Just found out about Sourcetree today and was very excited to use it and possibly switch from Tower.app. HOWEVER, I just noticed a huge issue that I can't work around and I'm scratching my head as to whether it's a bug or a "feature".

Basically I have a codebase with a ton of feature and hotfix branches. When I'm working on a particular branch and want to push my changes, I click on the Push button in the toolbar, and instead of getting a dialog like the one the Pull button displays (where the branch i'm working on is selected per context), the dialog shows a list of all branches in my repository -- MOST OF THEM SELECTED!!! -- which means if I'm not careful I would be setting off a nuke and pushing my changes to about 30 different branches rather than just the branch I am working on. Why in the world is SourceTree behaving this way? I even went in and unchecked all branches except the current branch and pushed, but the next time I wanted to push I had to do the same thing over again as all branches were again preselected!!! Very bizarre behavior IMHO and I'm wondering if this is a glaring bug or just a misunderstanding on my part. Perhaps I'm just used to using Tower.app but it doesn't have this NUKE ALL option disguised as a Push button.

I also noticed then even when my branch working copy doesn't have any changes, the Pull button in the toolbar shows that I have 36 changes -- not sure where the "36" is coming from.

It seems that I can get around this by right-clicking on my active branch and selecting "Push to origin/production (tracked)", the branch being "production", but why can't I do this from a button in the toolbar? The Pull button in the toolbar seems to be aware of context.

I'd really like to switch to SourceTree if there was a workaround or way to disable the PUSH TO ALL BRANCHES APOCOLYPSE "feature", but for now it seems to dangerous to use.

Any help would be greatly appreciated.

[Oleg Detinin · Accepted solution]

I will second a request to have a "dedicated push" functionality to the currently checked out branch. Even if current implementation is fully in "sync" with "git push" command, having every time unselect dozens of checkboxes is very user unfriendly. UI should help users with easy way of doing day to day tasks, not blindly follow some "command line" paradigms.

It is not fair comparison between command line and UI applications, as they are using absolutelly different design patterns (e.g. how can I select something in command line ??? why should I type more than required in command line. For example: "git push" makes more sence than "git push all").

[stevestreeting]

The top-level Push dialog default is to behave like a bulk operation, picking up all the branches you've previously configured to push to this remote (not all branches). Pushing to a single branch can either be accomplished using the sidebar (as you discovered), or when committing you can enable the 'Push immediately' option which just pushes the branch you're committing to.

The decision of which branches to select in the Push dialog is entirely down to which branches are configured to push to the given remote. You can see this via 'git remote show <remote>', the section at the bottom labelled "Local refs configured for 'git push':". Only branches which have been pushed to the remote before will have this configured, so when you create new local feature branches for example but don't push those explicitly, they are never selected in the top-level Push dialog. So essentially, the Push toolbar option is a 'Sync' button, where all branches that you've previously decided to push to that remote are selected.

So far, no-one else has raised this as unexpected behaviour in the 18 months we've been out, but I can still see your point of view, especially if other tools Push toolbar buttons pushed just the current branch. Perhaps a Preferences > Git option to flip between the two styles? It would still default to the current behaviour (as I say, no-one's complained about this before so I assume by that that most people are happy with the way it works now), but you could then tailor it to your preference.

[stevestreeting]

Also, the numbers on branches indicate how many commits your branch is ahead/behind the remote branch it is configured to track for pull. You can right-click the branch in the side bar and select 'Track Remote Branch' to see what branch you're tracking, and change it if you want. By default any branch you checked out from a remote will automatically track that remote branch, and the same with any branch you pushed to the remote.

[stevestreeting]

Funnily enough, someone else raised an issue today which indicates the 'git way' of indicating which style of default push you want: https://jira.atlassian.com/browse/SRCTREE-1019 - this would be the best way to implement this I think. Sadly, this git configuration setting is not reflected in the output of 'git remote show' - if it was SourceTree would automatically do it.

[Brian Tully]

Thanks for the response, Steve. That clarifies things a lot, though I have to admit I'm still puzzled by the implementation. Maybe it's because I'm just used to the UI paradigm that Tower.app uses. So if I understand you correctly, you're saying that the Push button in the toolbar, when clicked, shows a sheet containing all branches along with a checked checkbox if that branch is set for tracking, and then when I cick "OK" in the sheet, I won't be pushing my current branch to all the selected branches, but instead each tracked branch will push from their local branch to remote branch? In other words, the current branch working copy is not relevant?

If this is the case, then yes, this is behaving like a "Sync" button. And while you guys hit a home run on developing this unique feature, I think you struck out on the naming ;)

If I could make a suggestion, I'd suggest renaming the current "Push" button in the toolbar to "Sync" and retain its current unique functionality. Then I'd add a new button "Push" that behaves much like the "Pull" button in that it only acts on the current branch by default.

[stevestreeting]

Actually SourceTree simply mirrors the default behaviour of 'git push' without any parameters, if you haven't changed the configuration setting 'push.default' from it's initial setting, which is 'matching'. Git treats 'tracking' to mean on Pull, not Push by default. git push will push any matching branches on the remote. Therefore the naming convention is entirely consistent with the default git behaviour - the fact that Tower behaves as if 'push.default' is always set to 'current' (which is not the default git configuration) is a personal choice ;)

I plan to support alternate push.default settings in future, but as it stands the default Push behaviour is entirely consistent with git's own default behaviour when invoked with no context (other than the repo itself).

[Jacob Engstrand]

I would agree with other posters. The default behaviour of that button is rather odd, and it gets annoying over time. Pushing to all branches is something I would seldom do, if ever. Normally what I want is to push only to the branch I'm actually working on.

[Jacob Engstrand]

I would agree with other posters. The default behaviour of that button is rather odd, and it gets annoying over time. Pushing to all branches is something I would seldom do, if ever. Normally what I want is to push only to the branch I'm actually working on.

[torg]

This push all feature is completely unintuitive and downright dangerous.

As a first time user of sourcetree I got really screwed over by this.

I've never before pushed "all branches" in my life and I don't think the majority of git users have either.

Now I have to train myself to right click my branch and push from there and never ever push the giant button in the toolbar with the word PUSH on it.

[Philip T]

Thanks. You may be surprised to know that I actually don't see this file/folder. I have version 1.6.0.1 (1.6.0.1) so I assume it's not the old version (?).

[stevestreeting]

1.6.0.1 is the latest and that should definitely be using ~/Library/Preferences/com.torusknot.SourceTreeNotMAS.plist (sorry, forgot the .plist in my last post). I just did a quick test here changing a setting and that file is definitely the preferences file getting updated with 1.6.0.1.

[Philip T]

May you paste me the path to the preferences file so I can watch out next time?

[stevestreeting]

~/Library/Preferences/com.torusknot.SourceTreeNotMAS (assuming you're not using the old Mac App Store version). The ID still has the old pre-Atlassian company name in it precisely because we didn't want to change it & break the prefs upgrades :)

[Philip T]

I am on Mac. I guess it's also an one-off issue for Mac then? Now I know I will watch out next time I upgrade. Thanks!

[stevestreeting]

Hmm, not sure how that happened then - your settings are stored in the standard place, under ~/Library/Preferences so shouldn't have been wiped. Please do let us know if it happens again!

[Philip T]

Ah, I see. The new update must have overwritten my previous preferences. Nice (or yike) to know it does that so I know to manually recover whenever I upgrade next time. Thanks!

[stevestreeting]

It shouldn't lose your settings when you upgrade, except as a one-off when you move to our new installer: http://blog.sourcetreeapp.com/2013/05/13/new-installer-updater-for-sourcetree-for-windows/

[Philip T]

Just found this.

Yes, I am annoyed by this default behavior. In previous version actually (two months ago?), only my current branch is selected when I click on "push" - instead of now, every branch is selected! So annoyingly dangerous. Maybe in previous 18 month no one raised the issue, because it doesn't select all like the current version?

[stevestreeting]

In Preferences > Git (Tools > Options > Git on Windows), set the Push Branches: option to 'Current' to get the behaviour you want. You must have set this option to 'Current' before, the default is 'Matching' which is the same as git's default.