tell update to run only if there are no conflicts

[Matt Harbison]

On Sat, 11 Apr 2015 06:23:17 -0400, Lasse Kliemann  
<lasse at lassekliemann.de> wrote:

> Suppose I have changed some files in my working copy, then run
>
> hg pull
> hg update
>
> and the incoming changesets do not concern the files that I have changed,
> those are simply updated in the working copy, and my new parent will be  
> the
> last changeset that I pulled in (not considering multiple branches now,
> which might make it more complicated, I haven't thought about that yet).
>
>
> This workflow, in my opinion, gives a much cleaner, more linear history  
> than
> first commiting, then pulling and merging. It also works when the pulled  
> in
> changes concern the files that I was editing, provided that the changes  
> can
> be merged.
>
> However, if there are conflicts, the process is stuck until those  
> conflicts
> are resolved. In this case, I think that first commiting and then merging
> and resolving the conflict is the cleaner version.
>
> Is there a way to tell the update command to only do something if that  
> does
> not cause any conflicts?
>
> Part of the background of my question is that I'm looking for a command
> sequence that unexperienced users (who might never have heard of a  
> "merge"
> or something like that) can always use and which will never get their
> working copy stuck in some way. Currently, a working sequence is:
>
> hg commit
> hg push -f
> hg pull
> hg update
>
> This will always complete and make the user's changes known to the  
> central
> repository (where the push is to), probably be creating a new head, so  
> that
> I or anyone else on the team who is more experienced can see what the  
> user
> did and also do merges, resolve conflicts, etc.
>
> (For my applications, this is one of *the* reasons why we prefer  
> Mercurial
> before anything else, because Mercurial is the only system I know of  
> where
> such a sequence exists. Git, for example, cannot do it, at least not  
> without
> certain add-ons, which still have to be written. I recently discussed  
> that
> on the Git mailing list.)
>
> A drawback is still that we get that highly non-linear history. So I  
> would
> prefer:
>
> hg pull
> hg update --only-if-no-conflicts
> hg commit
> hg push -f
>
> Is that possible or would it be possible to implement?

You might want to follow this:

   http://bz.selenic.com/show_bug.cgi?id=4404


Someone posted an alias called "restore" a few years back on one of the  
mailing lists, which would get the uncommitted files back to their  
original state after the update stopped with conflicts.  I have it  
bookmarked at work, but I can't find it now.


In the meantime, I think you can get a pretty good idea if there will be  
any conflicts with:

	$ hg status --rev .::  # changes between working dir parent and pulled tip

and seeing if any of the files are also named in

	$ hg status  # your changes

This should work even if you pull in unrelated branches.  (Try it first- I  
didn't have incoming on any repos I'm tracking).

--Matt