A new plea for merging while you have outstanding committed changes

[Aardwolf]

I've once posted about this before, but in the meantime I've been using
Mercurial for many more months, and apparently still I'd love to be able to
have it merge while I have uncommitted outstanding changes.

Here's the entry about this from the FAQ:

"4.30. Why won't Mercurial let me merge because I have uncommitted changes?

If Mercurial complains when attempting to merge with the message abort:
outstanding uncommitted changes, it means that the usual process of merging
in changes cannot proceed. Let us consider what would happen if the working
directory were "clean" - that is, there are no uncommitted changes and hg
diff produces no output: Mercurial would attempt to combine the revision
being merged with the revision represented by the working directory, leaving
modified files (potentially with conflicts) in their appropriate locations
in the working directory, with the modifications originating only from the
merge process.

Now consider what might happen if the working directory already contained
modified files - that is, hg diff produces output. Mercurial would first
have to decide whether the merge is really to involve the actual files in
the current directory or the "pristine" files recorded in the repository
history: with the former, it would have to make a backup of modified files
just in case the merge is subsequently discarded, and the merge operation
would mix up local changes with changes introduced by the merge itself; with
the latter, although the modified files could be "shelved", the user would
then need to work through a merge with potentially older versions of files
than those they had been editing, and for Mercurial to restore these
modified files afterwards to preserve a somewhat consistent view of the
working directory, a non-trivial operation like a merge might then be
required to combine the local changes in such files with the result of the
original merge operation.

In short, Mercurial is trying to keep one operation separate from another
(local changes versus the merge) whilst avoiding putting the working
directory into some kind of special state (suspending local changes until
they can be combined with the current revision). "

If you have uncommitted changes in your working directory, then you can see
this as a sort of patch. In 99% of the cases, this patch can be applied to
the new merged working directory without conflicts. If Mercurial would
refuse to merge when such a conflict between your uncommitted changes and
the repository state would occur, then I could understand it (though a
conflict editor could be shown as well).

But in 99% of the cases, the change is in different source code files, and
even in different branches that have no effect on my working directory
whatsoever! Yes, even if someone pushed a change to a different branch, I
still have to "merge" and can't do that with uncommitted outstanding changes
in my own working directory!

I will always have uncommitted changes, and there's nothing to do about
that, and want to be able to have them. I can't help it that our config
files are also on mercurial and often need personal changes that shouldn't
be committed. And I like to leave changes that are work in progress local.
Also, whenever I want to push, it is for backup. I prefer to push to our
central repository, and multiple times a day, because it is a backup that
way, committing locally is no backup. And the shelve and multiple changelist
tools still aren't reliable.

My way of working is limited to this: when I want to commit/push, I need to
pull/update first. Then I need to commit the files I want to commit, and
quickly review the changes. Then I need to push quickly, and it has to be
quick or someone else will push in between my commit and push. If I push and
get a message "... will create new heads..." then there's only one thing I
can do, and that is to rollback, then pull/update again, then commit again,
then try to push again. I can't use multiple commits locally, because
rollback can revert only a single commit, and once you've got multiple
commits you have to do the merge, and then the misery with my uncommitted
local changes begins.

I'd like to suggest a force flag (-f) that allows mercurial to merge while
you have uncommitted outstanding changes (at the risk of data loss, but I
know very well that there normally won't be data loss, and if there is, it
will be less than what some shelve tools have caused to me).

Also, I've never used git myself so far, but someone who was using git told
me he didn't know that problem there. Does anyone know if this is true or
not?
-- 
View this message in context: http://mercurial.808500.n3.nabble.com/A-new-plea-for-merging-while-you-have-outstanding-committed-changes-tp1029134p1029134.html
Sent from the General mailing list archive at Nabble.com.