Uncommitted changes and merge

[Marcin Kasperski]

> Before I commit I take it as habit to pull and update from the main
> repo. Then hg refuses to merge because I have local changes - even
> though there is no intersection between my set of committed files,
> my locally changed files, and the pulled changes.

I think this habit does not necessarily suit mercurial (and generally
distributed SCM) way of thinking. You developed your changes according
to the tree you had. Therefore it is good idea to commit the changes
on top of that tree, and then merge if necessary. So, the better
way is to:

   - pull (and merge if necessary) before starting to work on something
   - (hack, hack, hack)
   - commit when ready
   - pull changes made by others and merge them
   - push your changes to the central location

Why is it better? Well, it clearly separates your development from
the merge. In case there are conflicts, your work is safely saved
and commited, then you can think about conflicts and resolve them.

Also, the proces above does not force you to push after every commit,
you can develop some line, commiting the work to secure it, and push
it only after it is ready.

Finally, note that you can just do 'hg commit; hg push'. In case
there are new changes on the main repo, push will tell you. So
the practical way is to

   - pull and merge before starging the work (well, sometimes
     even clone to get separate starging point for a branch)
   - (hack, hack, hack) and commit (and repeat as many times as you need)
   - push
   - if push refuses to work and told about multiple heads, pull,
     merge, commit (those three are nicely aliased as 'fetch') and
     then push again

> Is mq the solution to my problems?

Not quite IMO. mq can help you keep your local code not indented to
be pushed - you can save your debugging/local code as mq patch. But
it is a bit tricky, as you will have to take care of pushing/pulling
the patches when necessary, avoid saving 'true' changes as a patch
accidentally etc.

Personally I think that it is GoodThing (and PossibleThing) to
organise debugging code so it can be safely commited (and shared
between developers). In many cases it suffices to wrap those
print's with ifdef's/if's and sometimes to develop central patch
(not applied to development versions) to strip them before release
build. Apart from normal advantages (many people can benefit from
the same debugging code), it also helps if you need to spawn
separate branch....