version control - What's the easiest way to commit and push a single file while leaving other modifications alone?

Question

I'm relatively new to Mercurial and my team is trying it out right now as a replacement for Subversion.

How can I commit and push a single file out to another repository while leaving other modifications in my working directory uncommitted (or at least not pushed to the other repository)?

This happens for us with database migrations. We want to commit the migration to source control so a DBA can view and edit it while we're working on the code modifications to go along with that database migration. The changes aren't yet ready to go so we don't want to push all of them out.

In subversion, I'd simply do:

svn add my_migration.sql  
# commit only the migration, but not the other files I'm working on
svn commit -m "migration notes" my_mygration.sql

and continue working locally.

This doesn't work with mercurial as when I'm pushing it out to the other repository, if there are changes to it that I haven't pulled down, it wants me to pull them down, merge them, and commit that merge to the repository. Commits after a merge don't allow you to omit files so it forces you to commit everything in your local repository.

The easiest thing that I can figure out is to commit the file to my local repository, clone my local repository, fetch any new changes from the actual repository, merge them and commit that merge, and them push my changes out.

hg add my_migration.sql 
hg commit -m "migration notes" my_migration.sql 
cd ..
hg clone project project-clone
cd project-clone
hg fetch http://hg/project
hg push  http://hg/project

This works, but it feels like I'm missing something easier, some way to tell mercurial to ignore the files already in my working directory, just do the merge and send the files along. I suspect mercurial queues can do this, but I don't fully grok mq yet.

Answer 1

It's been almost 2 years since I originally posed this question. I'd do it differently now (as I mentioned in a comment above the question above). What I'd do now would be to instead commit my changes to the one file in my local repo (you can use the hg record extension to only commit pieces of a file):

hg commit -m "commit message" filename

Then just push out.

hg push

If there's a conflict because other changes have been made to the repo that I need to merge first, I'd update to the parent revision (seen with "hg parents -r ." if you don't know what it is), commit my other changes there so I've got 2 heads. Then revert back to the original single file commit and pull/merge the changes into that version. Then push out the changes with

hg push --rev .

To push out only the single file and the merge of that revision. Then you can merge the two heads you've got locally.

This way gets rid of the mq stuff and the potential for rejected hunks and keeps everything tracked by source control. You can also "hg strip" revisions off if you later decide you don't want them.