Is it possible to unbundle bundled changesets into a new branch in a repository? I have tried switching to a new branch before performing the unbundle, but that doesn't work.
Basically I have started a new development line and realized my commits should have been in a new branch. I've done hg strip to remove the changesets into a bundle and now I would like to recommit this bundle to a new branch.
I suppose I could recreate patches for each commit and then recommit each manually (or perhaps write a script to do it), but this seems unnecessary. Thanks for the help!
In general, unbundle will add the old changesets exactly as they were (starting off from the same parent changeset). A nice alternative to recreating patches for each commit might be in using the transplant or rebase extension (I'd go for rebase in this case).
No. The branch attribute is part of the changeset itself and altering it would alter the hashid, essentially making it a different changeset. A bundle is just a push/pull done manually, and it can't alter the changesets so it can't change their branch. The only things that can are things that actually modify the changeset or recreate it like export/import, transplant, histedit, mq, and convert.
You could clone your repository to a temporary repository, unbundle the bundle into it, check the changes, and if you're satisfied, push them to your main repository. If you don't approve of the changes, simply delete the temporary repository and the bundle.
Related
I am trying to do something very simple: create a new branch. But I messed up. Where did I make the mistake, and how do I fix it?
I am the only user of Mercurial. I had revision 54 committed and pushed to remote repository. I wanted to create a branch based on revision 53, so I updated my local copy to revision 53, made changes, and committed (ignoring the warning about "it's not the head"). Then when I am trying to push to remote repository, it says
abort: push creates new remote head
Maybe I needed to tell Mercurial that I want to create a new branch? If so, how and at what point?
Thanks!
You tell Mercurial that it can go ahead with
$ hg push --force
You need to force it since multiple (unnamed) heads are normally discouraged. The problem with them is that people that clone the repository wont know which one to use. But since you're the only user you can just go ahead and push.
The alternative is to use a named branch (with hg branch) and then you'll use
$ hg push --new-branch
to allow the creation of a new branch on the remote. Named branches have the advantage that they make it easy to distinguish the two branches. They have the disadvantage that they are permanent. Permanent means that you cannot remove the branch name from the changesets on the branch — the name is literally baked directly into the changeset.
Bookmarks provide a way to have non-permanent branch names, see hg help bookmarks.
Another reason for this error: probably there are some UNMERGED changes form the central repo in your default branch.
hg up default
hg merge
hg ci -m "Merge"
hg pus
I did this. Using TortoiseHg ... this is how I fixed it:
In settings, I enabled the Strip extension then right clicked the branch i did not want, Modified History - strip. If you have pushed, then it needs to be stripped from all other repositories, including workmates who have pulled your unwanted branch.
An alternative is to merge the unwanted branch into your main branch, but do not take any of the changes from that branch - I am unsure of how that mechanism works.
Many times it happens that I have few commits on my local Hg repository which I don't want to push and sometimes I want to remove the local branch altogether. But I cannot rollback more than one commit which leaves me no choice than creating a new clone and download the whole repository again. This feels stupid, since if I could just delete my local branch which has not affected the remote repository in anyway, then I wouldn't have to create and setup a new clone. So, is it how it is in Mercurial or is there some way to discard a local branch?
Thanks!
If you enable the mq extension (bundled with Mercurial), you can use hg strip. Be careful, though, as this will modify the history of your repository. The safe method is to clone your repository up to the revision preceding the creation of the branch you want to discard, then to pull the remaining changesets that you want to keep.
I know its too late but it may be useful for any one:
If your branch is not pushed yet.
First rollback changes hg rollback only if you have done commit but
not yet pushed
Second run hg update --clean
Third run hg branch any-existing-branch
Fourth run hg pull -u
If you find yourself doing this often perhaps you should be using bookmarks instead of named branches. http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/
I am aware that rollbacks can remove commits from the latest changeset in a local repository. However, is it possible to remove all the latest commits since the previous push without having to re-clone the share repository?
You can use the hg strip command, part of the mq extension:
hg strip REV
This will remove that revision + all its descendants.
Before you try this, make a copy/clone of the repository to experiment in.
You could make a new repo with hg clone:
hg clone -r last_good_changeset localrepo newlocalrepo
If you are using mercurial eclipse, you can rollback once, then shelve those changes, then export the multiple sequential commits as patches, strip those commits, then import those patches in the same order, so in case you had conflicting patches, they overwrite each other in the desired way.
Finally you can unshelve your first rollback. This achieves the same effect as if you were rolling back more than once.
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.
Suppose that:
I have a repo called MyRepo.
I have uncommitted changes in my working directory.
I do a pull from Repo1 and that creates a branch in MyRepo
I want to do a merge of what I already had in my repo with what I have just pulled.
As described here, the merge process changes the state of the working directory.
In my scenario, I don't want to loose the uncommitted changes that are in my working directory because at that point, I'm interested in changing the state of MyRepo; not the state of my working directory.
Is there a way to go through the merging process, including resolving conflicts manually, without affecting the content my working directory? Can this process be done in temporary files only? Or should I shelve my changes, do the merge and then unshelve to restore my working dir to the state it was before the merge?
Use shelve or attic extensions to temporarily stash your changes while you merge.
You could clone your repository to your latest checkin, merge the changes with the clone, commit, and then pull the new changeset from your cloned repository back into your current one.
You can't do that. As the documentation says, merge really is a working tree operation. Resolving conflicts without testing the result is crazy. Either shelve or commit the changes and then do the merge. If you don't want the commit to be visible anywhere, you can commit the change, update to the previous revision, merge the new branch, apply the temporarily committed patch and strip that temporary branch.
Just do it in a clone.
Clone MyRepo to MyRepo-merger, which will pull over all the committed changes, but not your uncommitted changes
Inside MyRepo-merger do a pull from Repo1.
Inside MyRepo-merger do all the hg merges you want
Inside MyRepo-merger push to either Repo1 or the original MyRepo
Pushing back to MyRepo won't alter the working dir of MyRepo, so that's a safe action.
Remember in Mercurial that clones are incredibly fast and cheap -- on modern file systems they use hardlinks under the covers so they're not even taking up much space on disk.
I'm pretty new to mercurial, but couldn't you clone from your local repository and copy your working copy over to the clone? You could then run your merge in the original? You'd preserve the state of your working copy in the clone while being free to allow the change of the original's working copy.
Test this first. I've never done it in hg.