If you hg push changeset A into repository myapp-v1 and then do an hg pull and hg merge to merge that into myapp-v2, is there a way in the myapp-v2 repository to identify that the changeset was originally checked into myapp-v1?
No. DVCS is DVCS and commited changeset haven't any origin-data after transfer to other clones
Workaround - permanent attributes of each changeset are
branch
author name
you can use these signs
Related
I use Git at work because Git is the team's choice. However, I prefer Mercurial for my personal projects. It's not a secret that Git and Mercurial branching models differ, and bookmarks in Mercurial are like branches in Git. I really like Git branches and use Mercurial branches rarely, just when I really need it, preferring Mercurial bookmarks. However, I miss something like git branch -d in Mercurial, because deleting a bookmark in Mercurial removes the bookmark only and preserves the immutable history. Is it possible to drop a bookmark in Mercurial with all of its changesets to the changeset where the bookmark has been diverged from?
In general:
hg strip revisions_to_drop
For your problem:
hg strip 'not ancestors(heads(all()) - bookmark(name_of_bookmark))'
(i.e. "strip all revisions which are not ancestors of heads other than the bookmarked head")
Assuming a sufficiently recent version of hg:
hg strip -B name_of_bookmark
So someone deleted a remote branch, but a changeset was lost when he deleted the branch.
I have the changeset on my local repository and tried to merge the changeset to my default branch, then I pushed, but I got an error "abort: push creates new remote head 650367cd0ff4 on branch 'rc'!"
There are few options, depending on the situation you have:
If the whole branch was stripped and you have that branch locally then you can push it again:
hg push --new-branch
This is recommended, because Mercurial will anyway send your local commits to remote repo every time you will do push (until you strip these commits locally). You can then close unwanted branch with --close-branch (this will leave all commits in repo, but just mark branch as closed/unused).
hg ci --close-branch
Graft the wanted commit locally from some branch to other:
hg graft -r 123
hg push
Create new remote head ("abort: push creates new remote head 650367cd0ff4 on branch 'rc'!"). It's nothing wrong, it just means that one of your branches will have two separate top commits. These commits can be merged together later.
hg push -f
I want to clone part of repository to non-tip changeset, so I use TortoiseHG -> Clone command, enter commit URL and clone. For some reason I get the clone to the last changeset, not that I wanted to clone.
How to clone to old changeset?
I've read that I can do this with git commands. Can I do it with TortoiseHG?
You clone not "commit", but "repository"
If you want to have partial clone, you have to read hg help clone
Procedure and syntax is common to all and any repositories, unrelated to BitBucket
To pull only a subset of changesets, specify one or more revisions
identifiers with -r/--rev or branches with -b/--branch. The resulting
clone will contain only the specified changesets and their ancestors.
hg clone -r <ID> SRC
hg help urls suggests second form of command
hg clone SRC#ID
GUI-way
In case of pure GUI in TortoiseHG "Clone" dialogue, expand "Options" enable "Clone to revision" and define this revision ID
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.
I am using hg-subversion, and I have 2 different hg repositories one from our svn trunk, and one from a branch of the trunk. I would like to link them somehow. At some point in the history both Hg repositories will be identical is there some way to join them?
In other words is there a way to relate the repositories from within Hg?
The technique I am currently using is to just export the second repository over top of the working copy of the revision they share, and then commit that working copy as a branch in Hg, but I lose the history this way.
Any advice would be great
You could try importing the two repos into one as if unrelated, then merging them. (When you say they share a common ancestor, do you mean that those ancestors have the same revision ID? If so there is a good chance that this will work well.)
hg clone repoA
hg pull -f repoB # may not need -f
hg merge
Can you re-clone the Subversion repository, giving the root of the Subversion repository as argument instead of trunk or one of the branches? I used hg clone svn+ssh://foo/bar/baz once, where svn+ssh://foo/bar/baz/trunk was the trunk and svn+ssh://foo/bar/baz/branches/quux was a branch, and in the end I had two named branches in Mercurial, the "default" branch representing Subversion trunk and the "quux" branch representing the like-named Subversion branch.
If you have outgoing changesets in your existing hg repos, you might be in a bit of a bind there. If there are just a few outgoing changesets, it might work to enable the mq extension and to convert the changesets into patches. These patches can then be re-applied on the new clone (in the appropriate named branch) and eventually pushed to Subversion.