Find Questions…

Close ×
First time here? Check out the FAQ!

How do I perform a forced push (push -f) from SourceTree?

Jeff Sherk asked this question · 26 karma ·

Hi

I am trying to PUSH a revision after a commit and it keeps saying

abort: push creates new remote head 1a2c34f5678
(did you forget to merge? use push -f to force)"

How do I use "push -f" from SourceTree?

Thanks

6229 views

6 Answers:

Steve Streeting [Atlassian] · 14,675 karma ·

SourceTree doesn't expose force push, because despite it being mentioned in that message from hg it's almost always *not* what you want to do.

It means that someone else has pushed before you. What you should be doing is pulling their changes, merging them (or rebasing your changes on top of them), and then pushing.

Jeff Sherk · 26 karma ·

Well I am the only one using the repository so not sure what is going on ... I had to create a new repository and then move all my files over to new repo in order to continue working on my project. I could not figure out how to merge anything (even though there should have been nothing to merge) and I could not cancel the push and could not revert to an old revision. It was basically stuck and would not push to the repo and would not let me cancel the push or cancel the commit.

Crystalmyst · 1 karma ·

Should this not be up to the user to do? Limiting features because they're dangerous is not helpful in any way.

Following a rebase workflow, where you always rebase and never pull/merge, you force push to update your branch when moving it on top of someone else's.
Right now, our entire company have to use the command line to do a rediculously simple command.

Can this perhaps be changed in a future release?

Steve Streeting [Atlassian] · 14,675 karma ·

Hmm. My problem with it is that every time I've seen force push done, it's been a mistake. I've seen other people use tools which have an easy "Force" option that they reach for immediately without understanding the consequences, and they've deeply regretted it later. A GUI is supposed to guide you through potentially unfamiliar territory without leading you into a bear trap - that's why I've resisted having easy access to this. The way I see it is if you really understand these dangerous options, you'll find a way to do it.

A rebase workflow is fine, and should not require a force push - so long as you haven't pushed those commits before. If you have, and you then rebase them on top of someone elses branch, then anyone that pulled or fetched the commits before you rebased them now has dead lines of development.

I guess if you have a situation where no-one ever pulls anyone elses branches (in git) then this might not be such an issue, barring having lots of orphaned commits which will eventually need cleaning up. If anyone did pull, or did base their own commits on top of those which you've now rewritten, then it's a world of hurt.

It's worth noting that the default behaviour of Mercurial 2.2 is to not even allow you to rewrite changes you've pushed (via phases).

Assuming you're talking about git, what sort of setup you have to avoid the nasty consequnces of rewriting? I'm thinking that if I did allow this, I'd require people to explicitly opt-in to have it displayed on the push dialog, perhaps in Preferences with a "Yeah, I really understand what I'm doing" warning message.

Crystalmyst · 1 karma ·

Good reply!

I perfectly understand that a GUI should be easy to use, and make it hard to screw things up on, but that doesn't nessecarily mean that features should be cut out. It simply means they should be difficult to access, or come with a couple of warning messages—As you say, just to make sure they really know what they're doing.

You're right with that, but although our company is only 25 people, we can frequently have people out and about, call in sick, lose their laptop, or simply want to share code, and therefore it's best to always push whenever possible. So there's a copy up on the cloud (Also handy for if you screw up your rebase and want to reset back, got a nice little ref sitting there)

You're quite right. It can be a lot of effort to maintain occasionally, but this is mostly down to communication. If you can communicate with anyone who has a local copy of your branch—Which 9/10 you do not need to do, due to it being your feature/dev branch—then you can co-ordinate the merge process, which for them is simply to delete their local ref of your branch. Simple.
Yes, clean up is also required once the repo starts to get a little too hefty. A simple archive and prune can do that for you.

It's also worth noting that git DOES allow you to rewrite history, and is one of the main reasons why it's such a powerful (yet potentionally dangerous) DVCS ;)

That sounds brilliant. If people screw things up by force pushing, then that's their fault. All you're doing is giving them the choice to force push if they really, really, really want to. Perhaps not only have a warning on setting the option to display the feature, but also a disable-able warning when selecting the force option in the push dialog, and not remember the force option of course.
That should make it sufficently difficult for anyone to accidentally force push, and only give the option to people that know what they're doing.

Do you have any more questions regarding my company's workflow?

Steve Streeting [Atlassian] · 14,675 karma ·

OK, that's pretty much what I thought - it does require people to know what they're doing, and does require an occasional 'cooridination dance'. If people fully understand that, it's no problem. The problem with GUIs is that they can give people a false sense of security when exposing things like this!

I still think that to support it, I'd like to make this an enableable option in preferences first rather than just always having the Force checkbox on the Push dialog with a warning behind that. The reason? People often push in a rush (maybe as they try to get out the door at the end of the day!), and this is a perfect time for rushed decisions and 'warning blindness'. I think if they got an error about creating new HEADs on the remote and the force button was right there, even with a warning they could quite happily click straight through just to get out of there even if they have absolutely no idea what it does. I think checking a box in Preferences to say "I want to see that option because I understand it" adds a little extra firewall that will make it more likely that it's only used by people that are fully aware of the consequences.

Crystalmyst · 1 karma ·

You got it. But it's the workflow we've gone for, and there's quite a number of others that use this too ()

Maybe I didn't word this part right:

Perhaps not only have a warning on setting the option to display the feature, but also a disable-able warning when selecting the force option in the push dialog, and not remember the force option of course.

I meant that perhaps there should be both a setting under preferences to enable the option (as you suggested), have a disable-able ("Don't display this warning again" checkbox) warning when selecting the force option when pushing, and have it never remember the force option, so the user has to click "force" every time they want to force.
Your suggestion makes so only people who know what they're doing use it.
My first suggestion makes so people who THINK they know what they're doing, reconsider it.
My second suggestion makes so you can't blindly force push as easily.

Ultimately, it's your application. Just putting forward ideas here to help out the problem that you wish you avoid :)

Steve Streeting [Atlassian] · 14,675 karma ·

Gotcha, thanks for the feedback on this. I've logged this as a future improvement here: https://jira.atlassian.com/browse/SRCTREE-1156

Mike Lehmann · 1,096 karma ·

SmartGit supports forced-push perfectly: It detects when it is needed and asks the user (if enabled in the preferences). No boring checkbox.

Crystalmyst · 1 karma ·

Problem with this, as described in the comments above, is that if it's too easy for the user to do, they can screw up their entire repo—while the feature should be there, agreed—and then blame the GUI for throwing their repo into chaos. It's best that that situation is prevented as much as possible, while still being easy to use for those that need to, and know what they're doing.

Mike Lehmann · 1,096 karma ·

By default the forced push is not possible, you first need to enable it in the preferences. Otherwise SmartGit will abort the push. I need forced push nearly every second day for rebased branches which only I control.

Daniel Rice · 1 karma ·

+1 for adding the ability to toggle --force onto a push command in Source Treeforce. Its not the tools responsibility to prevent a user from doing something stupid, IMHO. I'm an experienced Git user and rebasing a branch that I've pushed up (usually for code review purposes) is a best practice in my book.

Andreas L · 1 karma ·

Any news on this for git?

Or is there maybe a better way to accomplish what we are doing with force push?

We use gitflow, and before merging a working branch (feature/bugfix/hotfix) to develop or master, we do a squash rebase from the parent branch (master or develop). We squash the working branch in order not to clutter the parent branch with a lot of intermediate commits. Then we need to force push the working branch to origin, rewriting history of the working branch. Finally, the working branch is merged to the parent branch, creating a single commit for the added feature on the master branch. (Or sometimes a few commits if applicable and desired during the squash.) Working branch is then deleted.

(If we do not squash commits, it is very hard to encourage everyone to do many intermediate commits, and many commits is of cause valuable if something goes wrong, HW failure or whatever.)

Crystalmyst · 1 karma ·

https://jira.atlassian.com/browse/SRCTREE-1156

This has been mered into 1.7.0, and has been there since. I'm using it now.

Alex Ford · 1 karma ·

I'd like to add my two cents. I also agree with many others about limiting features. I don't mind obfuscating some more dangerous features in some kind of an "advanced" menu or something, as long as I can get to it. This is the absolute number one reason why I HATE the official Github mac/windows client. It hides A TON of stuff, including push & pull (which is really irritating). Whenever I am forced to drop to the command line it lessens my opinion of the tool.

I know what I'm doing when I force push and I really like sourceTree. Please add the ability to do force push. I don't care if it's in blinking red text that says the world will explode if you use it, just add it please. I don't think it's atlassian's job to make sure I don't make a silly mistake; I think a clear warning message would be just fine.

I do want to give props though for creating the aboslute best cross-platform git GUI I've yet to use. I'm so glad there is a "fetch" button at the top instead of just "pull". You guys have done a stellar job of putting all of git's complicated options into a nice interface that's easy to look at. Now if we could just add in some of these things that you deliberately left out I would be a very happy customer. I'd even be a paying customer for this product if there was such an option. It's that good.

Edit: I didn't notice that this was added, my bad. I am very grateful :)

Sean Westlake · 1 karma ·

Where is the option to enable force push?

I have version 1.3.2.0 and it is up to date.

Alex Ford · 1 karma ·

It's only in version 1.7.0 and higher. Sounds like you're using the version from the App store yeah? It's no longer maintained (which is a shame). Get it from the website.

Looking for something else?

Find Questions…

or Browse other questions tagged:

or Ask a Question