I think you are/were misunderstanding that extension. The (very seldom used!) share extension is for when you want multiple working dirs pointing to the same underlying repository -- instead of the much more normal one to one relationship between repos and working dirs.
There's no unshare because there's no bi-directional link.
Here's an explanation:
You create a new repo using hg init
or hg clone
:
repoA
\-- .hg (repoA's repository)
If you created another clone you'd have another working directory with another repository inside it. This is what's done 99.9% of the time.
repoA (the one you already had)
\-- .hg (repoA's repository)
repoB (the new clone)
\-- .hg (repo B's repository)
\-- hgrc (config file with a [paths] default=../repoA)
However, if you use hg share
you'll get something like this:
repoA (the one you already had)
\-- .hg (repoA's repository)
repoB (the new shared repo)
\-- .hg (a symlink-like pointer to ../repoA/.hg)
So it appears bidirectional only because they have the exact same repo under the covers. If they're on different machines/volumes then repoB
is unusable if repoA isn't available -- which is the opposite of what a DVCs is supposed to do for you.
So, in answer you "unlink" by deleting repoB. If there are uncommitted files in repoB that you don't want to commit into repoA you can do something like this:
hg clone -U repoA newRepoB # create a clone with no working dir
cp -a repoB/* newRepoB # excludes all files including .hg (and other .* files)
TL;DR: don't use share
; it is almost never the right choice.