That is, does Mercurial have a command to tell where it was originally cloned from?
The following question seems to not serve that purpose: Mercurial repository identification
I can't recall special command for it, just because I always read repo's hgrc [paths] section by eye due to fact (hg help config)
The following special named paths exist:
"default"
The URL or directory to use when no source or remote is specified.
'hg clone' will automatically define this path to the location the
repository was cloned from.
but if you want hg command and trust hgrc's content (which can be edited at any time), you can use hg config paths.default which output key from repo-config, without warranties of using this URL for the whole lifetime of repo
Related
I have often used this approach to dot file management in git, where I create a bare git repo "~/.dotfiles" and us $HOME as a work tree. With the shell alias config I can then add dot files from the home dir quickly (as in config add, config commit
alias config='git --git-dir=$HOME/.dotfiles/ --work-tree=$HOME'
I wonder if a similar setup is possible in mercurial.
You can use a regular repository for that[^bare] and clone it with the share extension. Creating a new home dir as one-liner:
hg --config extensions.share= share $HOME/.dotfiles $HOME
For more information see hg help share. For information how to ignore changes to untracked files, see hg help hgignore.
[^bare]: If it is important for you to have no files in the .dotfiles, just hg update null in ~/.dotfiles. That’s the root of the repository (before anything got added). Mercurial needs no special bare state.
I have a mercurial repository with a clone on several computers. In particular, I have a Ubuntu computer where the repository resides in ~/.vim and a Windows computer with a related repository in C:\Users\ben\vimfiles.
This repository contains subrepositories, some of them git subrepositories. For example, from .hgsub:
pack/thirdparty/start/signify = [git]pack/thirdparty/start/signify
I wanted to merge changes made in each repository. So I cloned the repository from my Ubuntu computer to a USB stick, plugged it into my Windows computer, and pulled from the repository on the Windows computer into the clone on the USB stick. So far, so good.
Now I go to merge, or even just update to any of the versions coming from the Windows computer. I got an error like this:
pulling subrepo pack/thirdparty/start/signify from /home/ben/.vim/pack
/thirdparty/start/signify
fatal: 'C:/Program Files/Git/home/ben/.vim/pack/thirdparty/start/signify' does not appear to be a git repository
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
abort: git fetch error 128 in pack/thirdparty/start/signify (in subrepo pack/thirdparty/start/signify)
[command returned code 255 Thu Dec 13 11:24:15 2018]
After a bunch of digging, I eventually solved the issue by manually editing the .git/config file in every single git subrepo to change the origin path from /home/ben/.vim to C:/Users/ben/vimfiles.
What's the correct way to do this using only Mercurial commands or configurations? Using TortoiseHg, when I update (but not merge!) I can select any of the saved paths to pull subrepos from. This seems to manually override the paths.default configuration for the pull operation. But, that setting seems to be ignored by the git subrepos.
From the mercurial's documentation on subrepositories (accessible on command line through hg help subrepos):
Subrepositories
...
Remapping Subrepositories Sources
A subrepository source location may change during a project life,
invalidating references stored in the parent repository history. To
fix this, rewriting rules can be defined in parent repository hgrc
file or in Mercurial configuration. See the [subpaths] section in
hgrc(5) for more details.
Documentation on subpaths:
subpaths
Subrepository source URLs can go stale if a remote server changes name
or becomes temporarily unavailable. This section lets you define
rewrite rules of the form:
<pattern> = <replacement>
where pattern is a regular expression matching a subrepository source
URL and replacement is the replacement string used to rewrite it.
Groups can be matched in pattern and referenced in replacements. For
instance:
http://server/(.*)-hg/ = http://hg.server/\1/
rewrites http://server/foo-hg/ into http://hg.server/foo/.
Relative subrepository paths are first made absolute, and the rewrite
rules are then applied on the full (absolute) path. If pattern doesn't
match the full path, an attempt is made to apply it on the relative
path alone. The rules are applied in definition order.
Is there any Mercurial command or Python API that could yield the repo name? This will help developing cross-repo scripts.
The only related solution that I found is to parse the .hg/hgrc [paths] section 'default' config option.
[paths]
default = ssh://server//path/tools
There must be a more elegant solution, I think.
There is no real concept of a "repository name" in Mercurial (a repository doesn't "know" or care about its own name). I think you mean "last past component of the default pull path"?
If so, then parsing the output of hg path default would be the most direct way to get that information.
However, you should note that the default path can (and often is) changed: think of cloning a local clone time for testing:
$ hg clone http://server/lib-foo
$ hg clone lib-foo lib-foo-test
$ hg clone lib-foo-test lib-foo-more-testing
The lib-foo-more-testing clone has a default push path back to lib-foo-test.
This means that parsing hg paths default wont be much more reliable than using basename $(hg root) — both can be completely different from the (base)name of the repository that was originally cloned.
If what you really want is to get an "identity" for a repository, then you should instead use
$ hg log -r 0 --template "{node}"
The first changeset hash in a repository will normally uniquely identify the repository and it will be stable even when clones change names. (If a repository has two or more roots, then the zeroth changeset can in principle differ between clones. People will have to actively try to make it differ, though.)
If you want to get last segment of path for remote default alias, processing output of hg path default will be better choice
If you want to get local directory name of you mercurial repository, I haven't good solution, except checking code of Notify extension (in which, after some tricks, you can get project-name)
all,
I have searched for this problem for long time and tried different methods.
I want to maintain my code on the server through only SSH. But when I run this:
sudo hg clone -v ssh://carl#hostname//home/carl/Java/Projects/peta/
Mercurial keeps telling me remote: abort: There is no Mercurial repository here (.hg not found)!. Some articles said that the path should be correct and there should be a .hg directory there. But I have checked it for several times and I am sure there is a .hg folder at the right place.
I also tried
hg --config ui.remotecmd=/usr/bin/hg clone ssh://carl#hostname//home/carl/Java/Projects/peta/
But it failed as well. What other problem it could be? Thanks.
Solved
I finally fix the problem. Previously, I create a repository on my local machine, and scp all files (including .hg) on to the server. I try to remove .hg directory first, and create a repo on the server through ssh (hg init). Then hg clone works!
Extraction from hg help urls
Some notes about using SSH with Mercurial:
SSH requires an accessible shell account on the destination machine and
a copy of hg in the remote path or specified with as remotecmd.
path is relative to the remote user's home directory by default. Use an
extra slash at the start of a path to specify an absolute path:
ssh://example.com//tmp/repository
this means, at least, that you can't use the same URI and change only one/two slash it it: at least one path will be non-existent.
Consequence of the quote and error message: you must to debug (with any ssh-tool) and find correct path to needed directory. you can:
use scp (f.e) and copy known file from known location
SSH into remote host in interactive session and verify path (both?) by hand, i.e: ssh ..., cd ..., pwd, verify output of pwd
... any other debugger
When you'll get good path after login, you have to check next point of failure - .hg dir permissions
After verification of these checkpoints you'll get clone and some bonus in the form of understanding "What happened before"
HTH
I don't know if this really helps but, according to the FAQ:
hg clone ssh://USER#REMOTE/path/to/repo
They are using only one / after the USER#HOST. Maybe you can try that way.
César Bustíos's answer is almost correct, but that tries to clone from remote to local. To opposite way, we have to add the local path. In the case it is the current directory, it will be a dot.
hg clone . ssh://USER#REMOTE/path/to/repo
Hope it helps. :)
Running on Debian, to solve my problem, I have added the following line to my /var/lib/mercurial-server/.mercurial-server configuration file after the [paths]
[paths]
/ = ~/repos
...
And don't forget to issue this command afterwards: sudo -u hg /usr/share/mercurial-server/refresh-auth
I’m just getting started with Mercurial, and I’ve read Joel Spolsky’s Hg Init tutorial, which I liked.
I’m wondering: let’s say I have a private repository and I work on it for about a month. Then I decide I want to centralize it or make it public, like on bitbucket.org. I want to retain all the history.
The intuitive thing would be to use hg clone, but according to the docs:
The location of the source is added to
the new repository's .hg/hgrc file, as
the default to be used for future
pulls.
I don’t think this is what I’d want, since the source is my local, private repository, and the destination is the public server. I don’t want the public server trying to pull from my private repository in the future thinking it’s the central one. I hope this makes sense.
Do I have to tweak the .hg/hgrc file on the server manually? Am I approaching this correctly?
BitBucket's help says it's as easy as making an empty repo on BitBucket, then pushing to it:
... create a new empty repository via the "Create repository" page. We will assume that this repository is named blonk and is to be found on http://bitbucket.org/jespern/blonk.
Now, just push to it:
$ cd ~/Work/blonk # our existing hg repository
$ hg push http://bitbucket.org/jespern/blonk
...
Done!
You can edit .hg/hgrc in your repository to include the default path to Bitbucket:
$ cat .hg/hgrc
[paths]
default = http://bitbucket.org/jespern/blonk
Now you can simply enter hg push and hg pull without having to specify the full URL.
Doing this operation using 'hg push', as described, is probably the best way to do this, overall.
However in other circumstances it might be convenient, or reassuring, to note that all of the Hg state is contained within the .hg directory, and so simply moving this directory is enough to move the repository.
For example, if you have ssh access to a machine at example.com, you can tar (or zip) up your .hg directory in the 'private' repository, unpack it in, say, ~/repo/foo on the remote machine (thus creating a directory ~/repo/foo/.hg there), and then simply clone this:
$ hg clone ssh://example.com/repo/foo
This does have a slight back-door feel to it, I agree. However, there's nothing really under-the-hood happening here, and no editing of configuration files is necessary. When I do this, I find it less confusing than the 'proper' way.