Let's say I updated to an older revision in my working directory to do some tests, and now I want to switch back to the most recent revision.
I thought tip would do the trick but no, this tag is the most recent revision on the repo, not only in my current branch.
Is there any tag to update to that means "most recent commit of your current branch"?
hg update with no argument will do the job. When you don't specify any revision, the update command will automatically update to the most recent commit of the current branch. That was easy after all.
If no changeset is specified, update to the tip of the current named
branch and move the active bookmark
https://www.mercurial-scm.org/doc/hg.1.html#update
Related
In Mercurial , How to clone from a specific revision to the last one using ?
For example repo A have one line history from changeset 0 to changeset 100. and I want to clone A to my local repo from changeset 90 to last one (100).
Looking through the help, I noticed the -r flag but that only clone 1 specific changeset.
And if there is no way to do it can somebody explain why its not implemented ? its considered a bad thing to do ?
Thanks.
You can't.
The current state of the project is all changesets from the beginning of time up until the specific changeset, you cannot prune older changesets without rewriting the history of the repository to permanently get rid of them. This will also make the repository incompatible with the original that contains the old history.
In short, you will have to do one of the following:
Prune the old history, permanently getting rid of it, which will make it impossible to push/pull with original clones that still has that history
Live with the history
The parameters to the clone command that specifies revsets thus only allow you to set an upper limit. This may allow you to avoid whole branches, if they aren't merged into the branch you end up cloning, but the clone command will always clone everything from the beginning of time.
For every changeset you clone, every predecessor will be cloned as well, and this cannot be avoided.
I forgot to switch my working copy back to the correct branch and made some changes.
How can I commit the current changes (but not all other changes in the current branch) to my original branch?
If I understand correctly, you have uncommitted changes that need to be on top of another branch.
My prefered way is to use the shelf functionality to save all your changes, update to the correct branch, and then un-shelf your changes back on the proper branch.
To do it on the command line, save the result of hg diff in a patch file, then update to the other branch and hg import <patch>.
Finally, just commit your changeset, as you wanted.
Shelve extension allow you to store WIP, get clean working dir, update to needed branch, release shelve
MQ exension (somehow overkill) allow to do the same thing, as shelve
At last, you can commit into wrong branch and rebase this changeset to the correct parent, using Rebase extension
How to checkout a single file from one branch to another in Mercurial?
Basically I want to copy a single file from a branch experimental to another branch production.
You can show any file at any revision with hg cat -r experimental filename. But this kind of behavior looks like a debugging patch, in which case I would consider transplanting (cherry-picking in other DVCS).
hg revert -r experimental filename could do it, not tested.
hg revert as suggested by #shellholic will indeed create a file from one branch in another branch. However the file will look as freshly added in history. Its actual history is not shown in the target branch.
I find grafting a better alternative.
Let's assume you have 2 branches, and you have created and worked on file f2.txt in the side branch. You were also working on the file f3.txt in the same branch at the same time.
Create another changeset in the source (side) branch, this changeset containing only the file you are interested in. If you already have such changeset, use it, no need to create a new one.
Update to the target branch.
Graft the source changeset. Mercurial will ask you if you want to use the changed version. Answer "c" (changed).
The result looks like this:
the file history is correctly preserved:
and f3.txt is not merged into the target branch.
We converted everything to Mercurial coming from CVS and so far so good. An issue we encountered today though is this situation.
Before the move to Mercurial I had a few pending changes from a while back, features that were started and later postponed for various reason. Odds are that someone else will finish those features months from now picking up from where I left off.
After cloning the new Mercurial repository I created separate branches to isolate those features.
It left me with something like this (made up rev. number)
hg update default
hg branch feature1
hg commit -m "Description of what I was doing in feature1"
hg update default
hg branch feature2
hg commit -m "Description of what I was doing feature2" (my tip is now here)
hg update default
hg push -f (to force the creation of my new branches, w/o affecting default, I haven't merged them)
During this the team have been working and pushing to our central repository so the default branch is say rev 40 (tip)
Now my push -f worked fine but positioned (tip) to my latest change -> 50:feature3 (tip). I was expecting the tip to stay at default on the central repository and just have my branches in there for someone to pick them up whenever. The graph also looks pretty funny when I use hgwebdir so I am pretty sure that's the wrong approach.
How would I do this? Should I close the branch first? Is tip actually important or just meta-data.
tip is always the most recent changeset added to the repository. From hg help revs:
The reserved name "tip" is a special tag that always identifies the most recent revision.
So long as the head of the default branch is what you expect, you'll be OK. No need to close the branch (but it's better to use hg push --new-branch if your version of Mercurial is new enough to support it).
tip is just an automatically-applied label referring to (I think) the most recent commit. Not a big deal; it's just there for convenience.
The tip label is pure meta-data and always points to the changeset with the highest revision number -- there is no more logic than that.
However, the fact that tip now points to a changeset on the feature branch wont cause you any trouble. When people make a clone, they will automatically be updated to the tip-most changeset on the default branch. So they can begin working right away after a clone. Furthermore, people who already have a clone will stay on their named branch when they run hg update. Here hg update takes you to the tip-most changeset on that named branch, e.g., on default if that is where you started.
People may think that hg update tip is the same as hg update, but that is only when there are no named branches at play. With named branches, giving an explicit revision name such as tip can changeset your named branch -- a plain hg update cannot.
I'm migrating a set of projects from Subversion to Mercurial. The projects currently use svn:externals to pull code from one into the others. I've been following the recommendation to point externals to a specific revision number and manually update it as needed (so that when I update to a past revision of the main project, I get the past version of the externals too).
The way to do externals in Mercurial seems to be with subrepos, but I don't see a way to peg them to a specific revision - it looks like Hg will always update the subrepos to the latest revision whenever I update the main repo. Is that correct? And is there a way to work around it?
In your .hgsub file you could use the http://[user[:pass]#]host[:port]/[path][#revision] (or local/filesystem/path[#revision]) syntax (see hg help urls for more examples) to anchor the subrepo to a specific revision. For that revision string you could even use #branchname or #tagname so that you track the tip of a specific branch (ex stable) or a moveable tag (ex: release) so that you only get the new version when a branch or tag on the remote subrepo are updated.
(copied from my comment above)
Turns out I was wrong. It doesn't update to the latest revision, it updates to the revision specified in the .hgsubstate file, which is version controlled and automatically updated at each commit. So this is actually easier than SVN externals since the revision doesn't have to be manually re-pegged; each revision of the main repo is automatically associated with the corresponding revisions of the subrepos.
It does seem that Mercurial subrepos are always updated to the latest tip of the remote repository.
I propose that, if you are using a particular version of a remote repository and updating that version only infrequently, it's better to fold that revision into your main repository. This means you are no longer dependent on the external source for a checkout.