Mercurial says "abort: outstanding uncommitted changes", I don't want to commit

Question

Scenario: Local repo, before I leave the office

$ hg status

M important/update1
M another/important/update2
M work/in/progress

I want to commit and push important/update1 and important/update2, because I want to pull these files to my local repo when I get home. I'm not ready to commit work/in/progress. In fact it does not even parse correctly. That file is opened in my IDE and I just want to leave it as it is.

Now I do: (hurriedly, the tram leaves in three minutes)

$ hg commit important/update1 another/important/update2
$ hg push

pushing to https://**censored**
searching for changes
abort: push creates new remote heads on branch 'default'!
(did you forget to merge? use push -f to force)

Ok. Colleague has pushed something... (tram leaves in two minutes...)

$ hg pull (really important update!)
$ hg update

abort: outstanding uncommitted changes

Crap. I need colleagues' update but I'm not going to commit work/in/progress, much less push it! And I just missed my tram...

How do you deal with this?

Solution 1

Use the attic extension to shelve/save work-in-progress temporarily.

Solution 2

If you don't want to use shelve, you can do it with just 3 commands:

hg diff > mylocalchanges.txt

hg revert -a

# Do your merge here, once you are done, import back your local mods

hg import --no-commit mylocalchanges.txt

Solution 3

A workflow for people developing several features/bug fixes at the same time:

One possibility would be to clone as many repositories as features you develop. But this might be expensive in disk space, time, and also confusing. An other possibility is to work on different subject on the same local repository (let's call it Main) but use just a second one to selectively commit one or several desired features to the central repository.

This is very well explained and detailed in this article:

https://blogs.oracle.com/tor/entry/mercurial_tip_checking_in_regularly

If you ever encounter the following error messages:

• “abort: push creates new remote heads!” (potential multiple heads)
• “abort: crosses branches (use 'hg merge' or 'hg update -C')” (working dir in a different branch than pulled changes), or
• “abort: outstanding uncommitted changes” (impossible to merge because of local modifications)

then the article above explains why all this is happening, and proposes a workflow to avoid these problems. Note: it is also possible to use mqueues patch mechanism to push your changes (see comment#1 of the article).

Hope it'll help.

Solution 4

I usually use the TortoiseHg shelve extension, which you can also activate to use on your cmdline:

[extensions]
tortoisehg.util.hgshelve =

Now you can use the commands:

$ hg shelve

If you know that the update won't interfere with our work, you can also force pull/update (hg pull -f).

Solution 5

If you're pushing just to expose code to the network so that you can pull and continue working at home, I don't know that your colleague should be pushing to the same repo. You could consider using a developer repository: a repo for your personal use (either by permissions, or just by enforcement/politeness).

Certain program (such as FogCreek's Kiln SW) provide this capability, but even if you just store repos on a network/shared drive, you should be able to create a personal repo there.

If this is not the case (ie: you don't have server permissions), you can also consider using a named branch. In this case, you would simply commit to your named branch and push that branch to the server. Presumably your colleague would leave your named branches alone and there would be nothing new to pull and merge. In terms of "branch clutter", yes they are present for the lifetime of the repo, but closing the named branch just before merging will remove them from your sight and resolve some issues.

> hg update <branch name>
> hg commit --close-branch -m 'closing branch <branch name>'

At the end of the day, I don't consider branch clutter to be a major concern unless you (a) have a giant team or (b) aren't closing your branches.

View more solutions