Detecting incoming merge/conflicts before they get pulled

[Kelly O'Hair]

Ahh..  forgive the basic questions, I'm fairly new to Mercurial...

Sounds like this will work then:

cd local-repo/..
hg clone local-repo local-clone-repo
cd local-clone-repo
hg pull parent-repo
hg update    <---   error return tells me there are merges/conflicts
hg status    <---   can tell me what files will need merging (starting with 'M"?)
cd ..
rm -f -r local-clone-repo

That should work.  Seems a bit overkill, but good enough.

Thanks.

---

FYI...

Teamware has a -n (like a dryrun) option so that you do a:
  bringover -n -p anyparent .
which provides you a file by file list that would be
updated, created, or will be in conflict. It's quite handy.
It's nice to know that a conflict is heading your way, because
merges must be done manually.

-kto

Matt Mackall wrote:
> On Thu, Nov 30, 2006 at 01:17:27PM -0800, Kelly O'Hair wrote:
>> Does anyone know how to find out of a 'hg pull' would result in
>> needing to do merges or conflicts? Without actually doing the pull.
> 
> In the usual usage scenario (no long-lived named branches), a merge
> will be necessary whenever remote adds heads. You can't do this
> directly with incoming, but this undocumented trick will work:
> 
>  hg incoming --bundle b remote  # grab a bundle of remote changes
>  hg heads -R bundle://b         # view heads of local repo + bundle
> 
> For compactness, you can use:
> 
>  hg heads -q -R bundle://b | wc -l  # get the number of heads
>  
>> The hg incoming tells me that changesets need to be pulled, but
>> not if they would result in conflicts.
> 
> File-level conflicts can't be detected without essentially attempting
> to do a merge. Which makes it dependent on your choice of 3-way merge
> tool.
> 
> But that shouldn't be a huge problem. Simply copy your repo, set
> HGMERGE to a script that complains about conflicts, and attempt the
> merge. If your repo is large, you can copy everything (including the
> working dir) with hardlinks.
>