I'm trying to do hg pull from another computer but hg is not giving me the latest version. It might be that I'm on the wrong branch. What can I do to resolve the error? When I make hg diff there is no diff but I know that is is not the latest version.
hg diff will never show you any output irrespective of the currently changeset, assuming that you have no uncommitted changes.
hg pull does not update your working dir to any revision - it just pulls the changesets into your mercurial repository without updating your currently checked our revision
You'll need to update your working copy to whatever revision you want. If there is only one branch involved, a simple hg update will do the trick. If there are several branches involved and the new changesets are on another branch, you'll need to tell mercurial explicitly that you're also ok with a branch change during update: hg update --check. Alternatively you can also try hg update --rev tip after the pull. If there's no branch switch involved and necessary, you can also tell pull to update immediately after a successful pull (but it won't switch branches): hg pull --update
Related
I am working in branch A and am using eclipse mercurial plugin to manage version control.Mistakely while pulling and updating the changes from the remote repository I pulled and updated changes of all the branches of my project.Now my branch A has changes of other branches say B , C , D .. as well.
I go-ogled and found out that hg rollback is likely the solution however I am not sure.
How do i undo my last pull and update? Any suggestion would be appreciated.
For a direct hands on How to revert a Mercurial hg pull?. Also look the Mercurial FAQ (7.13).
The hg update is never a problem, just do hg update YOUR_LOVED_REVISION_NUMBER and your working directory is again with all your stuff, and only your stuff.
Assuming you and only you works in the A branch, the hg pull is either a problem, just other's work in other's branches in your backstaged Mercurial internal history. If you like your history (DAG) clean then you may hg strip those annoying branches in your local repository.
Assuming the A branch is co-worked, then the hg pull just imported the other's work to your local copy of the project.
I ran hg update -r REVISION to revert a branch to a previous revision, but when I try to push this to a remote repository it says "no changes found". How can I accomplish this?
To revert the files to a previous revision you can use
hg revert -r REVISION
This will change your working directory files to what they were at that revison. Then you
will need to commit these changes before pushing.
hg update -r REVISION changes the working directory's parent to be that revision as well as changes the contents of the working directory to that revision. This is not what you want here.
hg update only affects the state of your working directory, not the repository itself. If you want to "undo" the effects of one or more previous revisions, you will need to change the repository by committing a new changeset that reflects those changes. You could do it manually but hg's builtin backout command makes this easy to do. See a brief description here. There is a detailed explanation of backout here.
For Mercurial, right now there is default branch and newfeature branch... is it true that if I am on
the newfeature branch, and do an hg pull and hg update, it will always ask me to merge? (if there are changesets that I pulled)
Also, it seems that I cannot just do hg merge? I need to use hg heads and then look at what the newfeature branch's head is (say it is revision 6880),
then I need to hg merge -r 6880? Because otherwise, will Mercurial merge the newfeature branch with the default branch automatically? I cannot do hg merge -b newfeature, it seems, as there is no -b option for hg merge.
Is there an easier way other than using hg heads to look for the revision to merge? Isn't there a more automatic way?
You've got two questions there, let me take them one at a time (with a little paraphrasing):
Q. When I hg pull and get a new head Mercurial suggest I hg merge. Do I have to?
A. No. Mercurial is just warning you you have more heads than than you did, and that if you don't like that arrangement you can merge to stop it. Named branches are heads, so you'll see that warning if pulling gets you a new head
Q. If I want to merge one named branch into another do I have to provide the revision number?
A. No. It's true that hg merge will only automatically select heads on the same named branch, but you can do hg merge -r newfeature and that merges in the changeset from the point of divergence up to the head on newfeature (6880 in your example) exactly the same as hg update -r 6880 would.
In either case, after committing that merge you'll have no heads on newfeature (the new, resulting head is on default because that was the branch name of your parent before you started the merge. However, just doing this after the merge:
hg update newfeature
...code....
hg commit
will create a new head on the newfeature branch, and you're right back as you were before the merge, except all of the changes that were on new feature are also available in default now.
If you pull a changeset or changesets from one branch into another branch that share the same root changeset. Mercurial will have multiple heads as you have so noticed. It will only suggest that you merge when you do an hg update on one of the branches.
You shouldn't have to specify which revision to merge to, assuming that you want to merge the tips of each of the branches. hg merge should suffice.
Your command structure should look as follow
hg pull -b 'branchYouWantToPullFrom`
hg update
hg merge
hg commit
hg merge works in your working copy, which is always connected to a specific branch.
You have to specify a branch name only if you want to merge your current branch with another branch: hg merge branch_name.
hg pull updates your repository with all remote changes. Then you have to update your working copy, that is connected to a specific branch. So, when you type hg update command, you update your working copy with all changes in your current branch.
If you want to switch to another branch you have to type hg update branch_name. You can type hg branch to know your current branch.
The only reason to merge with a specific revision is when you have three or more heads, a strange situation probably caused by some hg push -f (extremely bad practice). If you are in this situation, the right way to know which revisions you have to merge is hg heads. In a normal situation hg heads returns one head per branch, so you don't have to merge two heads of different branches if you don't want.
If you're working on a branch and someone has committed and pushed some changes on the same branch, you have to pull and merge before your push, simply with hg merge, no revision or branch.
I hope this will help you.
Is there a way to clone a repo that comes with subrepos, but without having Mercurial pull all the subrepos?
It appears that while hg clone -U can be used to obtain an empty clone of a repo, there's nothing that would convince hg update to avoid starting off by pulling all of the subrepos.
I should point out that it is crucial to retain the ability to easily sync to the head revision after creating such a clone.
This should do what you want:
REM Take a new clone, but do not update working directory
hg clone --noupdate %REPO_PATH% %DESTINATION%
REM Update working directory but exclude the certain subprojects
hg revert --all --rev %BRANCH% --exclude %SUBREPO_PATH_1% --exclude %SUBREPO_PATH_2%
This answer may add more than the question required, but provides some valuable notes on working with Mercurial when you can't update do to a bad subrepository path or revision.
Step 1: Clone the repository without any updates
hg clone --noupdate source_repository destination_repository
Step 2: Use revert to get the right files
hg revert --all --rev revision_number --exclude subrepo_1 --exclude subrepo_2 ...
At this point, you have a new changeset; you may need to make sure the parent revision is correct. When I did this, my new changeset's parent was changeset 0. To fix this I had to set the parent changeset AND switch branches (since my changeset was on a different branch).
Step 3: Change the parent of the current changes
hg debugsetparents revision_number
hg branch branch_name
That should do it.
Found a hacky way. It still requires all subrepos to be checked out once, but afterwards they can be deleted.
Clone the whole lot, including subrepos. No way around this.
Delete subrepos
hg remove .hgsub
I tried to convince Mercurial to hg remove .hgsub before the subrepos are cloned, but the best I got is not removing .hgsub: file is untracked.
If you have a subrepo, a working directory must include some version of that subrepo. That version may be a fixed older revision if specified, or the tip if not.
You cannot update your repo without getting the subrepos; if you had a complete working dir without them, you shouldn't be using subrepos - use truly external repos instead.
If your subrepos are pegged against a certain remote version, then updates after the first will not trigger a subrepo update - they're already up-to-date. But for the initial creation of the working directory, you will have to do a remote pull.
You can trick Mercurial by munging the hgsubstate file. But really, your model and the conceptual model differ, so you're probably not a good match for subrepos if this is a concern.
edit: If you find yourself cloning and then updating to the tip many times, try using local branches or mq instead. That way you only have to do the initial clone once.
How can I undo the creation of a branch in Mercurial? For example, if I issue the command
hg branch newbranch
How can I delete this branch if I decide I entered the wrong name? I'm guessing this must be pretty simple to do, but I have yet to figure it out. Thanks!
If you haven't committed yet, you can simply do a clean reset as per the manual (http://www.selenic.com/mercurial/hg.1.html#commands):
hg branch -C
This will reset the working directory's branch name to the parent of the branch that you just created.
if you haven't committed anything to it, it wasn't really created. so just issue another hg branch newname.
If its already commited:
hg clone -b branch1 [-b branch2 [-b ..]] oldrepo newrepo, i.e. every branch except newbranch, will result in new repo without the newbranch.
If mq extension is enabled then hg strip
Look into editing history before making permanent changes in repository.
Assuming you have not pushed to a remote repository, enable the mq extension and strip the branch off.