hg head lists multiple heads. How do you know which head is active in your working directory?
hg id gives you the revision of the working directory. hg sum provides the same information and some more. You might also want to check the compass extension which provides detailed information about the "location" of your working copy within the whole repository.
From the command line, you can use: hg log -r . to see the revision of your working copy.
Related
I am using Mercurial Shelve extension to shelve changes from command line. It works nice except when the changes that i like to shelve contain new added files(a) in working directory. Basically, it shelves everything except the new added files. I checked this by looking at the .hg/shelve stored changes.
How to shelve new added files (a status)?
This response is overdue, but you can use the following command to shelve all files (track / untrack) :
hg shelve -A
or
hg shelve --addremove
About this command, documentation says :
mark new/missing files as added/removed before shelving
You must pay attention by using this feature because after unshelving, your old untracked files are track.
These file are already to be commited in the last commit if no files are specified in hg commit command. You should use hg forget if you want untracked them again.
I assume you are talking about currently untracked files? You need to add the first.
So just do hg add for your new files and then hg shelve will also shelve them.
Thank you Tom. I am using Mac, so it didn't really worked. What did work was another mercurial extension 'hgattic' about which you can read more in my blog
http://margotskapacs.com/2012/10/shelving-uncommitted-changes-in-mercurial/
(see section 'Bug – Added Files Unable Shelve')
If the command line isn't absolutely necessary:
then just type (on Linux)
thg shelve
This allows you to easily shelve added (but not yet committed) files.
As a mostly Git user, I find Atlassian SourceTree the easiest way to deal with the odd Mercurial repo that I have to work with. It has shelving built in. The price is right, too (free).
Disclaimer: I work for Atlassian
I have accidentally created a repo in a sub directory of another repo
Since doing this the sub repo now contains a number of commits
I realised my mistake when I attempted an hg st on the original (parent?) repo and it complained of a file being inside a nested repo
What I would like to do is somehow move the sub repo history up into the parent then just delete the sub repo so I have just one repo
The dir structure is like this:
my original repo:
core/
my directories containing src code i'm trying to version control:
core/src/
core/test/
my accidental repo is in:
core/src/
e.g. its this one I want to push?/merge? up a level into the core/ repo, then just kill the core/src/ repo (by deleting the .hg dir)
I have read a few stack overflow discussions on this but they seem to be trying to solve more complicated sub repo scenarios. I'm hoping a straightforward (dare i say it simple) solution may exist?
I have not had much luck with the HG wiki on this either
Preserving history
Depending on the version you're using, you can use the Transplant or Graft extension to achieve your goal.
I've never done that and don't have time to test it before hand, but something like the following steps should work :
Move your actual core/src/ dir somewhere else, for example ~/temp.subrepo/
Remove the subrepo from the .hgsub file
Use the Convert extension to rename the files in the subrepo (see below for a quick example)
Transplant the changes : hg transplant -s ~/temp.subrepo.converted/ 0:tip
To convert the subrepo, you can use something like this :
$ echo include . > /tmp/myfilemap
$ echo rename . src/ >> /tmp/myfilemap
$ hg convert --filemap /tmp/myfilemap ~/temp.subrepo/ ~/temp.subrepo.converted/
Like I said, I'm not sure this will work out of the box, but it's at least a lead. If you have any problem, don't hesitate to ask.
History doesn't matter
Or maybe the simplest solution is just to remove the .hg directory in the subrepo, remove any mention of the subrepo in the .hgsub file of the main repo, and just add and commit the files :
hg add core/src
hg commit
You will lose all the history of the subrepo, but at least the solution is really simple.
I tried to update some files to old revision in many ways, but I haven't found yet.
(not permanently, just temporarily updating for testing)
For example, the following is OK in SVN.
svn up -r 100 foo.cpp
U foo.cpp
But in Mercurial, 'up' command doesn't permit file name argument.
Only is it possible to update entire source tree in Mercurial?
You'd have to use hg revert:
hg revert -r 100 foo.cpp
Note that this gives you local changes, as can be seen by running hg diff.
See hg help revert for more info.
This is fundamentally disallowed by Mercurial and other DVCSs. Both CVS and Subversion track which revision you have checked out on a per-file basis. You could have r1 of file x and r2 of file y. In a DVCs the entire repository is at a single version, which in Mercurial you can see with hg id.
As #Tom points out you can have modified files from different revisions, but if you want to see another revision without changes showing up you need to do the update in another clone (which given that local clones use hard links to be (a) instant and (b) space efficient) that's not much of a hassle.
What is the best/easiest way (or is it even possible) to add an existing repository to another existing repository as a subrepo?
Situation is I have an existing (main) project where I want to include a library project so that i can edit the library project from the main project, and commit the changes to the library project when comitting the main project.
Also: Do I need to clone/push/pull to the original library project, or is this done automatically when committing in the main project?
Regards
Jesper Hauge
The subrepo documentation confused me so much so I wrote a shell script to abstract that part of it away.
addsubrepo.sh
Call it like
$ cd $TOP_OF_HG_PROJECT
$ addsubrepo.sh $URL_TO_HG_PROJECT relative_path/you/want_to/put_the_subrepo
Reading the docs, the subrepo plugin supports this functionality.
I haven't used it yet, but will likely start using it in the near future.
It is improved every release of Mercurial, and I believe people are successfully using it. It seems to get a reasonable amount of attention, and was on the agenda for the last coding blitz.
According to the help, pull, push, commit etc should act on the subrepo as well. It sounds like a commit will check if there are any changes in the subrepo. If there are, they will be committed, and the new changeset in the subrepo will be recorded in the .hgsubstate file. This file, as well as the changes in the main repo will then be committed.
When you clone, Mercurial should see the .hgsubstate as well as the .hgsub file, and correctly pull the subrepo, and update to the correct revision.
You might want to use the deps extension.
Here's how I did it:
$ cd /projects/main_project
$ hg clone /projects/plugins/awesome plugins/awesome_plugin
$ echo plugins/awesome_plugin = plugins/awesome_plugin > .hgsub
$ hg add .hgsub
$ hg commit -m "added awesome_plugin plugin as a subp-repo"
Using TortoiseHg Synchronize, clicking "Pull" pulls down the 2nd most recent revision.
At the bottom of the Synchronize interface is a button, "Update to branch tip." Clicking this button pulls down the most recent revision.
What is happening here?
Command line hg tells this:
$ hg help pull
...
Pull changes from a remote repository to a local one.
...
-R is specified). By default, this does not update the copy of the
project in the working directory.
vs.
$ hg help up
...
Update the repository's working directory to the specified
revision, or the tip of the current branch if none is specified.
If you are new to mercurial or want to know you havent missed any options, this is could be helpful:
http://blog.hanxiaogang.com/hg-guide/