Mark is a graph advocate and field engineer for Neo Technology, the company behind the Neo4j graph database. As a field engineer, Mark helps customers embrace graph data and Neo4j building sophisticated solutions to challenging data problems. When he's not with customers Mark is a developer on Neo4j and writes his experiences of being a graphista on a popular blog at He tweets at @markhneedham. Mark is a DZone MVB and is not an employee of DZone and has posted 553 posts at DZone. You can read more from them at their website. View Full User Profile

Mercurial: Only Pushing Some Local Changes

  • submit to reddit

One problem we've come across a few times over the last couple of months while using Mercurial is the situation where we want to quickly commit a local change without committing other local changes that we've made.

The example we came across today was where we wanted to make a change to the build file as we'd made a mistake in the target that runs on our continuous integration server and hadn't noticed for a while during which time we'd accumulated other local changes.

The following is a rough diagram of the situation we had:


We had multiple file changes in our working directory which hadn't yet been checked in to the local repository or the central repository.

We wanted to push just the change in blue.

My initial thought was that I could check in just that one file into our local repository and then push it to the central one.

hg ci -m "mark: updating build file to fix build" -A /path/to/build.file

I then wanted to push that change but when I went to do so I realised that they were other incoming changes which we hadn't yet integrated with.

In order to integrate with those changes we need to make sure that we don't have any locally uncommitted changes which of course in this scenario we do since we deliberately chose not to check in some of our local changes.

One way around this would be to just force the push and ignore the need to integrate with the remote changes but that doesn't seem the right approach to me but I'm not sure what is.

We ended up just checking in everything we had locally, commenting out the bits that we were currently working on, merging with the remote changes and then pushing everything to the remote repository.

That's obviously a really poor way of solving the problem so I'd be interested in what a good way to solve this problem would be!



Published at DZone with permission of Mark Needham, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


John J. Franey replied on Sat, 2010/06/26 - 6:44am

Caveat: I use git exclusively. My answer is from that context. I expect hg and git to be similar.

Commit your local changes. If you don't want this commit to show in your history, that will be resolved in last step.

Create a new branch based from the latest from central and check it out into your workspace.

From the other local branch, checkout ONLY the files you want to send up to central.

Edit these files so they run within the latest from central, commit and push the branch.

Create and checkout a new local branch from the central build branch (the one you just added changes to). Merge in the first local branch you had started with and use an option that withholds committing the merge result.

In my own personal experience, early on with git, I had high anxiety around creating new branches. Eventually, that anxiety went away. Now, it is very natural for me to create new branches in my local repository in order to manage these sort of issues. The central repository never get these temp branches, and my colleagues are never bothered by them.

Chris Schmidt replied on Sat, 2010/06/26 - 2:35pm

  You can use the shelve extension to set aside changes you don't want to commit at a particular time.  That would enable you to commit the single file, pull/merge then push it.  Afterwards you can unshelve your changes back into the working directory and continue on. 

Viktor Nordling replied on Tue, 2010/06/29 - 3:06am

The best way I can think of is:

1. Commit the file that you want to change.

2. Clone your repo locally. This will only clone the committed files.

3. Push the clone to the remote repo.

Hope that makes sense.

Viktor Nordling replied on Tue, 2010/06/29 - 3:11am

Tor Norbye also wrote about this exact problem and has the same suggested solution as I just described (but he described it better.. :)

Michael Eric replied on Wed, 2012/09/26 - 3:41pm

The proper solution is probably use of Mercurial Queues, as Mike pointed out already. I was pretty skeptical about using MQ in the past, fearing it would add too much complexity to our workflow, but indeed, it does not, and it simplifies a lot many of our everyday tasks.

As a cheap alternative, in this case you could have committed locally, export the patch, and mail it to a coworker for the push... :)

linux archive 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.