I know that rebasing, already public repo, is not a good idea since we can end up with duplicated changesets (they have different ids, but the changes are the same as for the source files).
Here's the snippet from Mercurial Rebase Extension documentation:
You should not rebase changesets that have already been shared with
others. Doing so will force everybody else to perform the same rebase or
they will end up with duplicated changesets after pulling in your rebased
changesets.
But I'm interested what exactly could be a problem with duplicated commits? Can you give me some example of the possible problems that might occur? I've tried merging two branches with duplicated commits and had no problems, just two changeset with the same name exist on the merged branch.
what exactly could be a problem with duplicated commits?
Dirty history, additional head -> the need for +1 merge
Related
How can I duplicate a branch in Mercurial? I need the new branch to be against head (as the first one is).
The GIT equivalent (if I was in branch-a) would be:
git checkout -b branch-b
A Mercurial branch is a named entity that consists of all the commits contained within the branch. So in order to duplicate some existing branch, you must also duplicate all of its commits to new commits that are in the new branch. We then get into metaphysics arguments about commit identity. It's probably not a good idea to go here at all, but if you do want to go here, use hg graft to copy all the desired commits into the new branch.
A Git branch consists of a name containing a raw commit hash ID. So duplicating a Git branch under a new name is trivial. Note that the set of branches that contain any given commit changes dynamically over time: a branch that was only on feature/tall may now only be on master, even though that commit is still that commit, even via most of these metaphysical arguments. (Only the "no identity over time" argument lets us claim that this is not the same commit.)
Another way to put it is that Mercurial's branches actually mean something, but Git's don't. If you need true branches, you can't use Git in the first place. Don't try to import Git's bizzareness into Mercurial: you'll just make your own life miserable.
Meanwhile, though, Mercurial contains a DAG just like Git. If you use Mercurial bookmarks, those work like Git branches. It's probably wiser, then, to just use bookmarks and be done with it.
If all else fails, see hg graft.
the new branch to be against head
What is this (in usual business-term, not Git-lingua)? While in common (and in details) #torek is totally right, he forgot to write exact command-set, something like
hg up <rev-id>
hg branch <new-branch-name>
hg graft -r "branch(old-branch-name)" --log
I'm confronted with a Mercurial repository that has originally been a CVS repository. It has recently been migrated to Mercurial with cvs2hg.
The CVS repository had a couple of branches, lets call two of them "main" and "feature". "feature" has been branched off "main" a very long time ago. Between the branches, changes have frequently been "merged" by checking in changes committed in one branch into the other. There are frequently tagged "merge" revisions where "main" and "feature" have been equal.
When I try to do the first (real) merge in Mercurial, the three-way merge assumes that the "base" version is the revision when "feature" was originally branched off. This means that there is a lot of visual cluster with conflicts where "main" and "feature" are almost equivalent to each other but very different to the "base" version. This is so bad that the merge would take a very long time and would be error prone.
I'm wondering if there is a way to tell Mercurial that the base version is one of the tagged "merge" revisions, e.g.
hg up feature;
hg merge main --base "tag-xyz"
In this case, the merge would be easy.
I would recommend fixing your recent history. This is somewhat messy, but once finished, Mercurial's merges should work correctly out of the box.
First, find the most recent point at which the feature and main branches were exactly the same. Merge the equivalent commits (merge main into feature). This should create a new head with two parents (one from feature, one from main). Furthermore, that head should be on the feature branch, not the main branch. Since the commits are exactly the same, you should not experience conflicts. Next, you will need to rebase the rest of the feature branch onto this head.
Suppose the new head is commit abc. Again, this head has two parents, one of which is on the feature branch. That feature parent has a second child, which is also on the feature branch. Suppose that second child is commit def. Then you can perform the rebase as follows:
hg phase -f -d 'def::' # Unnecessary if you've never pushed
hg rebase -s def -d abc
This will change the commit numbers for def and all its descendants. If you have multiple instances of the repository, they will need to undergo this same fixup, or you will need to re-clone them. Otherwise, your repositories will get very messy when people push and pull.
Once you've done this, merging should "just work."
I made some changes to a file and committed it. (In fact there were several commits).
Then I wanted to revert to the earlier version and lose all those changes.
I did something like:
hg update -r nnn where nnn was the reversion number of the changeset I wanted to go back to.
That worked. I was happy.
Then, later, I had to push my local repository to the remote. But when I did hg push I got a message about there being two heads on this branch and one of them not being known to the remote repositiory. It suggested I merge before pushing. (I think).
I googled this and found a page that suggested I do "hg merge". I did that. Now the resultant file is back to where I started. I.e. it contains all the changes I wanted to throw away.
Where did i go wrong?
EDIT:
I have found this post Mercurial — revert back to old version and continue from there
where it says:
If later you commit, you will effectively create a new branch. Then
you might continue working only on this branch or eventually merge the
existing one into it.
That sounds like my case. Something went wrong at the merging stage it seems. Was I on the wrong branch when I did "hg merge"?
You're past this point now but if it happens again, and it's just a single file you want to revert then consider:
hg revert --rev REVISION_YOU_LIKED path/to/just/one/file.txt
That doesn't update you whole repository to a different revision, and it doesn't create any commits. It just takes a single file in your working directory and makes it look like it used to. After doing that you can just commit and you're set.
That's not the way to go if you want to undo all the changes you've made to all files, but for reverting a single file use revert and avoid multiple heads and merging entirely.
No, nothing went wrong at the merge stage – Mercurial did exactly what you asked it to...
What merge means is that you take the changes on your current branch, and the changes on the 'other' branch, and you merge them. Since your original changes were in the 'other' branch, Mercurial carefully merged them back into your current branch.
What you needed to do was to discard the 'other' branch. There are various ways of doing that. The Mercurial help pages discuss the various techniques, but there are pointers in other SO questions: see for example Discard a local branch in Mercurial before it is pushed and Remove experimental branch.
(Edit) Afterthought: the reason you got a warning about there being two heads on the branch is because having two heads is often a temporary situation, so pushing them to a remote repository is something you don't want to do accidentally. Resolutions are (i) you did mean to push them, so use --force to create two heads in the remote repository; (ii) ooops!, you meant to merge them before pushing, so do that; or (iii) ooops!, you'd abandoned the 'other' one, so get rid of it. Your case was (iii).
I faced today my first mercurial problem. I was in my repo, I modified a file and I did a
hg commit
hg pull
followed by
hg update
hg rollback
to repair what I've done, (but actually I didn't push anything)
The problem is that when I did the pull (that I should do before the commit, the head changed and so hg heads looks like :
- Modif from yesterday
- My modif
- Modif from last week
and now I see that someone also did another modification (via the http interface). What should I do to repair my local repo, (if possible modifying my summary) and push it after the 2 others modifications.
Thanks a lot. Quiet confusing, was easier on my "one-man" repo..
Your local repo doesn't need "repairing". This is a very standard case that you will see often if you use Mercurial a lot.
The issue is multiple heads.
You can either merge your heads, assuming your working directory is your version and there is only the other head:
hg merge
This will result in a merge changeset (same as if you were merging across branches).
Or you can enable the rebase extension to re-base your version onto the tip of the branch (the other head):
hg rebase --source<YourVersionNumber> --dest<TipVersionNumber>
This will not result in a merge changeset, and will simply transplant your changes on top of the changeset you specify as if they were born of that changeset all along (hence rebase or "new"basing).
Multiple heads is a funny sort of inner-branch branching... you can continue checking stuff in against your own head and change between heads using hg update. We block multiple heads per branch on our server, so our push would fail. I'd advise keeping multiple heads local as they are less clear-cut than branches.
I tend to work with Mercurial in one of two ways:
If the work is large in scale I will branch it off and follow Continuous Integration practices (constantly merging the main branch into my own etc). I then re-merge back into main when I am happy with the end result.
If the work is small in scale I will simply work against main branch and "merge" heads every so often. I say "merge" as I usually use rebase. Re-basing works great if the changes are simple and conflicts are unlikely.
My hard and fast rule: if I can't use rebase I put it on a branch born of main.
I'm in my branch, and I do this:
hg incoming /path/to/baseline
And I get a few changesets in the output.
Now do I just merge to pull in the changsets to my branch?
hg merge /path/to/baseline
Will my history show what was merged?
As long as I didn't touch those files, it will be automatic right?
You should really try all this out yourself! Make a couple of test repositories:
hg init main
hg clone main clone
and then experiment away. It's easy and safe since you're only playing around on your own machine. (This is actually what happens "behind the scenes" when you ask a question here: I try to make sure that the advice I give really works, so I normally have to run a few tests on a new repository to double-check.)
If you ran the tests, you would see that
You cannot give hg merge a path name (or URL) as argument. It takes a revision as the only argument. You need to hg pull /path/to/baseline to copy the changesets into your local repository and then hg merge.
The history will indeed show what was merged. A merge becomes a merge commit in Mercurial. That is a changeset with two ancestor changesets — both lines of development leading up to the merge are still in the repository.
Merges are without conflicts ("automatic") if the changes made in the two branhces don't overlap. If you edit different files in the two branches then there's certainly no overlap. But you can also edit different regions within the same file and still have a merge without conflicts.
There is a fine tutorial on the wiki and I've also written a beginners guide. I hope that helps.