How to keep uncommitted changes in a local mercurial repository, while still pushing/pulling?

Question

If i'm working on some files that I don't want to commit, I just save them. I then have other files I want to push to the server, however if someone else has made changes to the repository, and I pull them down, it asks me to merge or rebase.. but either of these options will cause me to lose my local changes that I have not committed.

What are other people doing to get around this? I find the documentation for the shelving extension hard to get my head around.

Note: I'm using Mercurial Eclipse to push and pull files to/from the server.

Any explanation of this would be greatly appreciated! Thanks!

---

Example:

I'm working on my website in Mercurial Eclipse. I have a new folder and new files that I don't want to commit to the server just yet. I've also modified some existing files and I don't want to make those changes live just yet.

Then something on my website breaks and I need to fix it, it won't let me fix it without rebasing or merging with the most recent tip of the repo and this will cause me to lose all my uncommitted changes.

What should I do with my new folder and files i've edited if I don't want to lose it? Re-cloning seems tedious. Copying the files to a new folder seems tedious as well. I'm sure Shelving or MQ will do what I want, I just don't know how to go about it yet.

Towner

Please tell us which shelving documentation you're using, and what parts you're having trouble following. – Delete

possible duplicate of Mercurial usability. @Jason: if you just want to reword your question, use the edit button, don't post a new question. – Timms

I can't find any documentation that deals with using the MQ extension in Mercurial Eclipse. I've gone through this documentation link'MqTutorial' . I guess I don't understand how exactly to use patches and the work flow. I'll add an example of what i'm trying to do in my question. – Towner

Answer 1

I'm sure someone will help you find a bad workaround, but the best route is to change you goals -- just commit. Code that hasn't been committed hasn't been written. If you positively can't abide having frequent commits in your history use Mercurial Queues with a queue repository and commit that. You can then pop the changesets, push/pull/merge, and the push them back on, and all you valuable work will be committed in the patch queue.

Officialdom

I can't seem to figure out how queue's work in Mercurial Eclipse. Any additional explanation of this would be greatly appreciated! – Towner

Now part of this was me not understanding pop/push and all that. So for anyone else wondering.. You create a patch (qnew), do whatever changes you need to make but don't want to commit, then qrefresh to update the patch, qpop to take the patch off and make any changes you want to push right away. qpush to go back into your patch. – Towner

I would use commit & strip rather than bother with queues. Its just simpler. – Hayrack

Answer 2

With reference to your example situation, here's what I would do (following Ry4an's strategy to just commit the things you're currently working on, but don't want to publish already):

Supposed you start working in a repository like this one:

$ hg status -A
C f1
C f2
$ hg glog
@  changeset:   1:7f3c6c86a92f
|  tag:         tip
|  summary:     add f2
|
o  changeset:   0:03ca1e6d5b86
   summary:     initial

That is there are 2 files and 2 commits/changesets. You do some work, let's say add a new feature, and then your working copy might look like this:

$ hg status
M f2
? f3
? f4

There are 2 new and 1 modified file. Now you have to fix a bug for which you also need any new changes in a remote repository. Snapshot your current work by committing it and pull the remote changes (in which order you do that does not matter, a pull by default does not touch the state of your working copy):

$ hg commit -A -m "snapshot feature work"
$ hg pull

This may result in a history like this:

o  changeset:   3:2284ba62de07            <-- just pulled in
|  tag:         tip
|  parent:      1:7f3c6c86a92f
|  summary:     edit f1
|
| @  changeset:   2:4a19d371a04f          <-- your interrupted work
|/   summary:     snapshot feature work
|
o  changeset:   1:7f3c6c86a92f
|  summary:     add f2
|
o  changeset:   0:03ca1e6d5b86
   summary:     initial

Now you can update-to/checkout revision 3 and start fixing bugs:

$ hg update 3
.. fix the bug ..
$ hg commit -m "fix a bug"
$ hg glog --limit 3
@  changeset:   4:5d3d947fb4af
|  tag:         tip
|  summary:     fix a bug
|
o  changeset:   3:2284ba62de07
|  parent:      1:7f3c6c86a92f
|  summary:     edit f1
|
| o  changeset:   2:4a19d371a04f
|/   summary:     snapshot feature work
:

Looks good, let's push your fix, i.e. make it live, while don't publishing your intermediate work:

$ hg push -r 4

This pushes all changes leading to revision 4, your bugfix, but no other branches in your local repository. You could also use -r ., which refers to the parent revision of your working copy, i.e. the revision you just committed.

Finally you can go back to your feature work and continue your work:

$ hg update 2
.. work, commit, work, commit ..
.. finally merge with the other branch, e.g. revision 4

These steps are on the command line, but I think it's not to hard to adapt the general concept to corresponding clicks in the Eclipse Mercurial plugin.

Some extra notes:

• You may want to bookmark your snapshot commit, so you don't need to work with revision IDs or numbers.
• If you want to publish your feature work in a single commit later, use the collapse extension once you're done.

Tenrec

Just a note: this is called the nudge technique. See hgtip.com/tips/advanced/2009-09-28-nudge-a-gentler-push – Evered