Seems like for both Mercurial or Git, if I don't commit first, then I can't push?
So if I don't commit (when not ready yet), I can't push to a remote server to back up my code? The code is in a notebook computer, being carried around, which can be somewhat fragile being carried around.
That's correct. The purpose of push is to share one or more commits with other repos. Neither are primarily intended as backups (though some people use them for that).
There are plenty of dedicated backup tools and online services. See Online backup for personal use for a list.
That's correct; you can't push uncommitted changes. However, just because your changes aren't ready yet doesn't mean you can't commit them. I have no experience with Mercurial, but with Git, you can amend a commit (git commit --amend) to modify it after it has been committed. You can also make a series of commits and then do an interactive rebase to combine them into a single commit. Or you can just make commits as necessary and not worry about making sure your history is completely pristine.
You are always ready to commit.
Commit often. Commit to a work in progress branch and distribute it as widely as you feel.
When you get to the state that you're currently referring to as "ready to commit", examine the divergence of your branch from the upstream, do a rebase -i to clean it up and make it look like you want.
This will be easier, safer, and just generally give you better results than trying really hard to get everything perfect before committing. Remember: A commit doesn't necessarily represent a desired permanent state of the universe. It's just somewhere you are. How you publish it is up to you.
git makes it very easy to publish a do-not-look-at-me branch for your work in progress that you can later move into your official codebase at whatever point and in whatever form you think best suits you.
Just make a new throw-away branch.
Commit half-baked changes into that branch, and push that branch.
When your changes are ready, squash your half-baked commits (using rebase), and merge the result into your master and delete the throw-away branch. (You can delete a branch from a remote repository using git push origin :branch – note the colon before the branch name.)
There is never a reason not to commit your changes, although there may be reasons not to commit to a particular branch when they’re not ready yet.
Lemme see if have the scenario correct. You have...
...but your annoying boss taps you on the back and says, "Hey! When are you going to push that change you mentioned in the staff meeting? We're all waiting for it!" He's standing there waiting for you do it, so how do you get him out of your hair quickly and easily?
This is easy. You want to be using the MQ extension. It's bundled with the standard Mercurial installation.
First add it to your .hgrc file.
[extensions]
mq =
To stash your uncommitted edits in a patch queue entry, do this:
$ hg qnew stash
$ hg qpop
Now push your older commits, so your boss will get off your back.
$ hg push
Finally, restore your working directory like so:
$ hg qpush
At this point, you still have the patch recorded in your patch queue. It's just marked as "applied" now. Finish editing your code, then do this to update the patch with your finished edits and a commit log message, then finalize the patch into a changeset:
$ hg qrefresh -m"Commit message goes here."
$ hg qfinish stash
That's the basics, but there's a whole lot more you can do if you want to get really fancy. The MQ extension is like a whole new world of revision control hiding underneath the Mercurial repository. It's like the Git stash, but more flexible and marginally less confusing.
Learn, mutate, evolve!