hg pull & co mix uncommittd changes

[Soh Tk-r28629]

> > > More importantly, it's the normal use case. People ought to work
> > > against the tip, and that ought to be easy.
> >
> > If we commit _before_ merge, then we are.
> 
> What if you're not ready to commit? What if the checkout you have is
> broken in an area you're not touching? If we force a commit before
> merge, then users will either:
> 
> - keep working on broken versions
> - check in bogus incomplete commits
> - incorporate unrelated changes into the work they're doing to get
>   things to work

All local changes are make against the local repo, and should be ready to commit with respect to the current state of the local repo. It doesn't make sense to anticipate future changes, and we shouldn't have to worry about something will break when we pull & update. And one of the best thing about distributed VCS is that I don't have to worry about what happen to the other side of town. Not until I start to pull the changes.

If the source repo is broken, we should be able to just abort the merge, get the source repo fixed somehow, then repull. We won't know something [that we didn't touch] is broken before the merging is done. That's why the ability to _easily_ revert back to pre-pull/merge state is important, and if the local changes had been committed, it would be just a simple 'hg undo'. But now we have to manually revert it through the .orig files, and keep our fingers crossed that we don't make any mistake when doing that. 

And, please, don't ask me to backup the repo first. It's just not right for any VCS to have to ask users to do that, in anticipation of some potentially surprises that could be avoided. Besides, I may not have the diskspace for this.

> Committing before merge means you'll have to do a branch merge later.

If we decide on making local changes, then branching is the way of life. It should be the VCS's reponsibility to managed and keep track of merges - bk does it particular well, perhaps partially owing it to it's nice graphical interface.

Without dragging this discussion, I share Kevin's thought on whether or not to begin a merge without the user explicitly requesting it. And IMHO, I would say the answer is no, if hg has detected local committed/uncommitted changes.

Any for me, I will remember to check before I pull ;)