Why can't I merge when there are uncommitted outstanding changes?

[Jason Harris]

Also some people when they are familiar with Mercurial use a few more advanced tools to clean up their revision history a bit before *pushing* Eg rebase, hist-edit, or mercurial queues.

For me I just commit with reckless abandon lots of the time without really thinking in huge detail about my commits (With CVS I used to have triple check that I didn't make some stupid goof that would be enshrined making me look like an idiot for all time.) Now I just commit, commit, commit, and then before I push I clean things up a bit if necessary. This is a *much* *much* faster workflow for me.  There is really no reason not to commit before doing other changes. Committing makes a "unit" package of the parts. This can then be moved around, reordered, etc if you need to.

Actually I find that in the end I don't always move things around. Its more common for me to do lots of commits and then occasionally rebase or reorder stuff before pushing.

(Admittedly I might find things frustrating if I couldn't occasional rewrite history before doing a push...)

Cheers,
  Jas


On Apr 22, 2010, at 5:10 PM, Mads Kiilerich wrote:

> Aardwolf wrote, On 04/22/2010 04:49 PM:
>> But again, if I have uncommitted changes to file A, I have committed changes
>> to file B, and on the "central" repository there are changes to file C. How
>> hard can it be to automatically solve this by the tools? Isn't that what the
>> tools are for?
>> 
>> Why do I have to manually do so many tricks for that situation? I'm here to
>> write code, not someone who loves constantly playing with version control
>> systems. They're a very good tool to me to look up file histories (what did
>> other people do), give my changes to the rest, and get their changes, but
>> that's about it.
>>   
> 
> You are trying to use a workflow that (often) works with CVS or SVN. And because these VCSs enforces a linear history you actually have to use a workflow like you describe. The disadvantage is that you don't know exactly what you are committing, and you can't verify that the merge is correct. And sometimes things go terribly wrong.
> 
> Mercurial always tracks whole repositories and doesn't encourage workflows where you have many different changes in your working directory at once. For example, when you merge then Mercurial will use the working directory to resolve conflicts,  and after the merge the working directory contains exactly how the changeset will look when you commit the merge. There can thus not be other changes in the working directory.
> 
> You have to change your work-flow a bit if you want to use Mercurial.
> 
> In your case I would probably wait with the merge until I am ready to commit my local changes, commit them, and then merge and commit the merge. If the merge goes wrong it can be discarded before commit and done again.
> 
> If I need the other changes in order to continue I would create another clone / working directory, pull the changesets that has to be merged into it, do the merge and commit, and pull the result into the first working directory and update. But note that the update with pending changes in the working directory is slightly risky if you end up with conflicts and can't resolve them correctly. Merging tracked revisions is more reliable.
> 
> In the trivial case where distinct files are changed then Mercurials work-flow is a bit overkill. But it is 100% reliable and works in all cases.
> 
> (And I suggest that you forget about extensions until you are familiar with these work-flows.)
> 
> /Mads
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/listinfo/mercurial