I am going from git to mercurial. Trying to find the equivalent of git-branches, I run into mercurial-bookmarks.
Given that I have no bookmarks. The workflow I follow is:
hg bookmark test_bookmark
hg update test_bookmark
How can I merge that back to the head, since there is no main bookmark?
You can get a list of heads with hg heads. This will usually include the bookmarked head along with any other heads you may have created. If, after pulling, there is exactly one head, there is nothing to merge (your history is linear). You may want to delete the bookmark in this case with hg book -d name_of_bookmark.
On projects which make extensive use of bookmarks, it is common to bookmark the "canonical" head #. This bookmark is checked out automatically when cloning (unless the user passes the -u or -U flags), and is roughly analogous to git's master branch, except that it doesn't exist by default. It helps keep track of which head to merge with, but unlike git, you don't need to give every head a name if you don't want to.
If you want to do a fast-forward merge (i.e. you want to move a bookmark forward to a descendant changeset), update to the descendant and do hg book name_of_bookmark. It's somewhat common to fast-forward # in this fashion, if your repository is using it.
Related
This question is not only technical. I want to get into the concept itself, too.
There is a foreign project on BitBucket (e.g. ObjectListView). And I need to work on two problems at the same time. In git I would just create to branches in my local repository after clonening.
But how would I does this with Mercurial?
When I create branches there I am not able to push my local commits back to the remote repository because of the missing '--allow-new-branch' option.
So it doesn't want me to branch.
In my current understanding I would just create a clone for each new feauter (branch). So this means I have to create two forks on BitBucket for one project when I want to work on two different problems.
How would you solve this?
There is some missing information here, so I'm not sure I know what your problem is. I'll try to take some educated guesses and cover a number of possibilities. Feel free to ask back if I failed to address your problem adequately.
First, you can definitely just create new branches if you wish to do that. You'll need to use hg push -f or hg push --new-branch (if you used a named rather than an anonymous branch) to make the remote server accept them (that's to prevent you from pushing new branches by accident). You will, of course, need write access to the repository (or fork the repository and work on that fork).
Second, if you just want to push the current revision/branch (and any associated revisions of a feature branch) and not sync the entire repository, then hg push -r . will do that (here, . denotes the current revision, you can also specify others). If you use that frequently, you may want to create an alias, e.g. submit = push -r ..
Third, if you actually need separate workspaces, it's probably more convenient to use hg share instead of cloning the repository. (Note that you'll first have to enable the share "extension" for that; the word "extension" is in quotes because it's actually a part of core Mercurial and not really an extension in the traditional sense.) hg share creates a separate directory that is still linked to the same repository, but has a separate checkout with separate files.
It is also important to understand that branches in Git and Mercurial are completely different things. Branches in Git, aside from naming specific commits, exist to keep revisions alive (so they don't get garbage-collected). In Mercurial, nothing ever gets garbage-collected, so you don't need Git-like branches for that purpose; instead, Mercurial has anonymous branches (which are sort of like detached HEADs in Git -- sort of) and named branches (which are used to label sets of revisions with a permanent name). Bookmarks can be used to put temporary labels on either type of branch (or specific revisions). Bookmarks + anonymous branches can be made to feel fairly Git-like if you desire that.
So, if you want a Git-like approach, you'd just create anonymous branches (and optionally put a bookmark on them for ease of reference, though having them as branch heads in two directories created with hg share can be the better choice if you wish to work on both concurrently without having to switch. You'd then use hg push -r . to push that specific branch to the remote repository (you may also need -f if you're creating a new head).
However, if it is not your repository, you may want to check with the owner what structure they prefer; for example, plenty of Mercurial users prefer named branches in order to be able to tell later which revisions belong together (sort of like a tag that spans multiple revisions).
I've got my IDE set to commit locally every time I save anything. I'd ideally like to keep an uncensored record of my idiot fumblings for the rare occasions they may be useful. But most of the time it makes my history way to detailed.
I'd like to know a good strategy to keep that history but be able to ignore it most of the time. My IDE is running my own script every time I save, so I have control over that.
I'm pretty new to Mercurial, so a basic answer might be all I need here. But what are all the steps I should do when committing, merging, and reporting to be able to mostly ignore these automatic commits, but without actually squashing them? Or am I better off giving up and just squashing?
Related question about how to squash with highly rated comment suggesting it might be better to keep that history
Edit - My point here is that if Mercurial wants to keep all your history (which I agree with), it should let you filter that history to avoid seeing the stuff you might be tempted to squash. I would prefer not to squash, I'm just asking for help in a strategy to (in regular usage, though not quite always) make it look as much as possible like I did squash my history.
You want to keep a detailed history in your repo, but you want to have (and be able to export) an idealized history that only contains "reasonable" revsets, right? I can sympathize.
Solution 1: Use tags to mark interesting points in the history, and learn to ignore all the messy bits between them.
Solution 2: Use two branches and merge. Do your development in branch default, and keep a parallel branch release. (You could call it clean, but in effect you are managing releases). Whenever default is in a stable state that you want to checkpoint, switch to branch release and merge into it the current state of default-- in batches, if you wish. If you never commit anything directly to release, there will never be a merge conflict.
(original branch) --o--o--o--o--o--o--o (default)
\ \ \
r ... ... --r--------r (release)
Result: You can update to any revision of release and expect a functioning state. You can run hg log -r release and you will only see the chosen checkpoints. You can examine the full log to see how everything happened. Drawbacks: Because the release branch depends on default, you can't push it to another repo without bringing default with it. Also hg glog -r release will look weird because of the repeated merges.
Solution 3: Use named branches as above, but use the rebase extension instead of merging. It has an option to copy, rather than move outright, the rebased changesets; and it has an option --collapse that will convert a set of revisions into a single one. Whenever you have a set of revisions r1:tip you want to finalize, copy them from default to release as follows:
hg rebase --source r1 --dest release --keep --collapse
This pushes ONE revision at the head of release that is equivalent to the entire changeset from r1 to the head of default. The --keep option makes it a copy, not a destructive rewrite. The advantage is that the release branch looks just as you wanted: nice and clean, and you can push it without dragging the default branch with it. The disadvantage is that you cannot relate its stages to the revisions in default, so I'd recommend method 2 unless you really have to hide the intermediate revisions. (Also: it's not as easy to squash your history in multiple batches, since rebase will move/copy all descendants of the "source" revision.)
All of these require you to do some extra work. This is inevitable, since mercurial has no way of knowing which revsets you'd like to squash.
it should let you filter that history to avoid seeing the stuff you might be tempted to squash
Mercurial has the tools for this. If you just don't want see (in hg log, I suppose) - filter these changesets with revsets:
hg log -r "not desc('autosave')"
Or if you use TortoiseHg, just go View -> Filter Toolbar, and type in "not desc('autosave')" in the toolbar. Voila, your autosave entries are hidden from the main list.
If you actually do want to keep all the tiny changes from every Ctrl-S in the repo history and only have log show the subset of the important ones, you could always tag the "important" changesets and then alias log to log -r tagged(). Or you could use the same principle with some other revset descriptor, such as including the text 'autosave' in the auto-committed messages and using log -r keyword(autosave), which would show you all non-autosaved commits.
To accomplish your goal, at least as I'd approach it, I'd use the mq extension and auto-commit the patch queue repository on every save. Then when you've finished your "idiot fumblings" you can hg qfinish the patch as a single changeset that can be pushed. You should (as always!) keep the changes centered around a single concept or step (e.g. "fixing the save button"), but this will capture all the little steps it took to get you there.
You'd need to
hg qinit --mq once to initialze the patch queue repo (fyi: stored at \.hg\patches\)
hg qnew fixing-the-save-btn creates a patch
then every time you save in your IDE
hg qrefresh to update the patch
hg commit --mq to make the small changeset in the patch queue repo
and when you are done
hg qfinish fixing-the-save-btn converts the patch into a changeset to be pushed
This keeps your fumblings local to your repo complete with what was changed every time you saved, but only pushes a changeset when it is complete. You could also qpop or qpush to change which item you were working on.
If you were to try the squash method, you'd lose the fumbling history when you squashed the changesets down. Either that or you'd be stuck trying to migrate work to/from the 'real' repository, which, I can tell you from experience, you don't want to do. :)
I would suggest you to use branches. When you start a new feature, you create a new branch. You can commit as many and often as you like within that branch. When you are done, you merge the feature branch into your trunk. In this way, you basically separate the history into two categories: one in fine-grain (history in feature branches), and the other in coarse-grain (history in the trunk). You can easily look at either one of them using the command: hg log --branch <branch-name>.
Is it possible to forcibly create new remote head when pushing ?
Suppose I have done some local commits on branch "default" then pulled and merged from remote.
Now, I would like to push my commits to remote creating new head and a bookmark but preserve existing remote head and tip - ie. my coworkers should not get my changes yet when doing hg fetch.
Basically this should be a short lived branch (thus not a named branch) for purpose of backup and code review by other before being fully merged into "main" head of default branch.
I've tried --new-branch but it didn't help - no new head was created and remote tip moved to my head.
You can use the --force option to force the creation of a new head.
The --new-branch option is used for named branch, in your case, we are talking of anonymous branching.
The reason why the "tip is moved" is because you merged the changeset recently pulled. Doing that, there's no way to do what you want.
You should just pull the new changes from the remote, and force push everything without merging, this will create a new head (called an anonymous branch), which can later be merged to the default branch by you or someone else after the code review.
You can also use a second repository to push your changes, but this is a totally different workflow.
You cannot preserve tip when you push: it is a pseudo-tag that always points to the newest changeset in a repository. The concept of tip is deprecated in Mercurial because tip can change meaning more or less randomly depending on the order of pushes — as you've seen.
The only way to create a new head is to, well, create it :-) By this I mean that you need two heads — one with your changes and one with the main code you want the colleges to pull and merge with. With only a single head (the one you got after running hg merge) there's no way to signal to the colleges that they shouldn't use it.
A much better approach is to use a separate repository on the server. Go to your repository management software and create a fork for your changes. Then push into that and tell your colleges to review it. They'll pull from your clone and look the changes over. If they like them, then they can merge with the main code and push to the normal repo. If they don't like the changes, then they can throw away their local clone, strip the changesets, or maybe just rollback the pull.
My solution to this issue is to use a previous revision for the start of the bookmark, if there is none or you just do not want to, you can make a dummy commit (like a small change to a README file, etc.) and bookmark the revision before that.
I think hg bookmarks need a lot of fine tuning before they become like git branches, but the process I describe is pretty much what is explained in the mercurial bookmarks kick starter.
For example, if your currently at revision 250.
echo >>README
hg ci -m "enabling bookmark branch_xyz"
hg book my-tip # optional but nice to have
hg book -r 250 branch_xyz
hg up branch_xyz
# hack ... hack hack
hg ci -m "awesome feature xyz (in progress)"
hg push -fB branch_xyz
now this bookmark lives on the server for others to work with ... but can be easily pruned later
I've just got a problem with hg push command. What I did - Firstly I created 2 branches hot-fix-1 and hot-fix-2 made some changes in each branche, merged it back to default and closed those branches with the command:
hg commit --close-branch
If I start hg branches I have the following output:
default 29:e62a2c57b17c
hg branches -c gives me:
default 29:e62a2c57b17c
hot-fix-2 27:42f7bf715392 (closed)
hot-fix-1 26:dd98f50934b0 (closed)
Thus hot-fix-* branches seems to be closed. However if I try to push the changes I have the next error message:
pushing to /Users/user1/projects/mercurial/mytag
searching for changes
abort: push creates new remote branches: hot-fix-1, hot-fix-2!
(use 'hg push --new-branch' to create new remote branches)
and it does not matter which command I use hg push -b . or hg push -b default
So the question is how I can push those changes to repository without creating new branches.
P.S I used to work with git and was hoping that similar branching model can be used in Mercurial. Thanks
First, as many others have pointed out, using a named branch for short lived work is not a recommended practice. Named branches are predominantly for long lived features, or for release management.
Given that you are in this situation, there are a few options available. All of them involve modifying history (as you're obviously trying to change something you've done).
One is to just push the branches as is, learn from the experience, and move on. If the rest of the team is fine with this, then it's a case of adding --new-branch to your push command.
If the rest of the team, or you, really want the history to be clean, then you'll need to dig deeper.
If you aren't pushing, then definitely make a clone of your current repo. This way you have a copy of the original work to fall back on.
I see 2 main approaches here. Strip off the merges and rebase your branches onto default. This will get rid of the named branches or graft/transplant your changes. Both will be the same end result, but the implementation is slightly different.
If you merely want to use graft, that is now a built-in function starting with HG 2.0. It replaces the transplant plugin, and is much nicer to work with as it uses your usual merge tool if there are conflicts.
To use it, update to the default branch. Then, use the command:
hg graft -D "2085::2093 and not 2091"
the string after -D is an hg revision selection query. In your case, you'd likely only need '{start}::{end}' where start is the changeset at the start of the branch, and end is the end changeset of the branch (ignoring the merge).
If you did several merges, you'd have to pick and choose the changesets more precisely.
The other option is to strip the final merges, and use the rebase command that is part of the mq plugin.
You'll have to strip your merge changesets to get rid of them, and then update to the tip of the branch you want to keep. Select the start of the first named branch, and do a rebase. This will change the parentage of the branch (if you're familiar with Git, then this is very much like it's rebase).
Then repeat for the second branch. You should now have one long branch with the name default.
Just do the:
hg push --new-branch
It will send over those branches, but they'll be closed on the receiving end too, so no one should be bothered.
See my comment on the question for why Named Branches are best saved for long-lived entities like 'stable' and anonymous branches, bookmarks, or clones are more suitable for short lived things like hot-fixes and new features.
Your hot-fix changes were made on branches. Regardless of whether the branch is active or closed, it does exist.
To push the changes to the server (without rewriting history), you must use the --new-branch option (e.g. hg push --new-branch`).
Since you merged the branches into default, there will still only be one head (as you have already seen in your local repo).
If you really can't live with pushing the branches to the server, then you must rewrite your local history as suggested in Mikezx6r's answer.
In addition to the methods he mentioned, you can also import the changesets into a patch queue and apply them to the tip of your default.
I am a little confused about how to rollback to a tag in Mercurial. (which I am very new to)
Say I have a tag called "Version-1.0" which was several revisions ago. lets say we are at r400 now
Now if my managers were to tell me they don't like the direction things have been going and basically want to ditch everything since that tag and go back to Version-1.0.
Well I can checkout that tag with:
hg update -r Version-1.0
Ok so now I am back to the version 1.0 tag, and if I were to never need to make a change this would be fine. However, as soon as I make a change and commit, I now have 2 heads (my new changes to Version-1.0 and r400 the stuff the managers want to ditch).
So now I need to merge with r400. I don't want to. (I don't really want to wipe all those changes off the earth, I would like them to remain in my history so I can go back to them later if management changes their mind again) but I currently don't want any of them.
What do I do?
update
An answer stated:
You could clone the entire repository up until the tag, then use that clone as your "new" central repository.
If my central repository is hosted by bitbucket, I am not sure how to do this. If the current one is at URL https://jisaacks#bitbucket.org/jisaacks/hgml and I want to clone it up to the tag to a new repo named hgml2 (that doesn't exist yet) I tried this command locally on my machine:
hg clone -r Version-1.0 https://jisaacks#bitbucket.org/jisaacks/hgml https://jisaacks#bitbucket.org/jisaacks/hgml2
I get this error:
abort: cannot create a new http repository
Log on onto bitbucket and click the "Fork" arrow icon in the upper right corner. Now you can open the "advanced settings" to fork from a tag.
You could then rename the first repository to something like "myproject-abandoned-foo-changes" and reuse the original name for the forked repository, where you will continue development.
edit: you could also do a no-op merge. The linked wiki page explains that this might be bad because your history will be contaminated with the unwanted changes, but I think in your case this might be exactly what you want as it would preserve your changes while avoiding the "switching everything to a new repo" issue you complain about.
You can use hg revert. The following command restores your repository to a certain tag and discards all local changes.
hg revert -r tagname --all
The "correct" way to do this in modern Mercurial is to close the branch:
hg up head-i-dont-like
hg commit --close-branch
While this was originally added to close named branches, it works equally well with anonymous branches (what the OP has). In particular, it will only affect the head it is committed on, and not any other heads on the same named branch.