When I try to hg rebase -s 1775 --collapse, I am asked to merge all the files I touched since rev 1774. How can I avoid that?
Details
I am just learning how to rebase. I successfully tried the example given here, and a few minor variations. However, in my own repository, when I try the same steps, I am asked to merge a boat-load of files when I rebase. Here's what I do. What am I doing wrong?
hg update -r 1774
hg tag "Started-New-Feature"
hg rebase -s 1775 --collapse
I thought maybe it was because I had updated to -r1774, so I updated to tip after tagging -r1774. Same result.
hg update -r 1774
hg tag "Started-New-Feature"
hg update
hg rebase -s 1775 --collapse
The hg tag creates a new rev -r1784. So I tried updating specifically to -r1783. Same result.
hg update -r 1774
hg tag "Started-New-Feature"
hg update -r 1774
hg update -r 1783
hg rebase -s 1775 --collapse
I've searched the web and SO for related questions and didn't find anything, which doesn't mean answers don't exist. Pointers to existing answers are welcome.
Edit:
This seems related to a reported mercurial bug that was fixed in 1.4. I have version 1.1. I tried updating to 1.4 or later, but sudo apt-get install mercurial says I have the latest, and the download link on the mercurial page is currently broken. So maybe the answer is just getting the latest version, but hopefully there's another way around this.
Are you using ubuntu? If so you can use the launchpad ppa version of hg, which tends to be very currenty https://launchpad.net/~mercurial-ppa/+archive/releases
Related
Is there a problem with Mercurial's guide for fixing case-folding collisions or is there a problem with the way I am implementing the solution.
The solution as provided on the Mercurial wiki is as follows:
hg clone -U repo repair
cd repair
hg debugsetparents <bad revision>
hg debugrebuildstate
At this point, Mercurial will think you have the bad revision checked
out and all the files are missing (status '!'). To fix the repo, we
simply have to do:
hg rm -A <file causing the collision>
Now hg st should show the troublesome file in state 'R' and all other
files in state '!'. Now we can check in our fix:
hg ci -m"fix case collision"
To get all our files back, we just check out again:
hg co tip
The problem files are: SomeFile.bash and Somefile.bash. I originally had Somefile.bash and I would like it to now be SomeFile.bash. Also to note, version 157 is happy, no collision, but version 158 is where I have introduced the collision. The head of the repository is currently at revision 160.
I have implemented this solution as follows:
hg clone -U my-repo-url repair
cd repair
hg debugsetparent 160
hg debugrebuildstate
hg status (reveals that everything is 'missing' (!))
hg rm -A Somefile.bash (responds that SomeFile.bash has been removed, notice case change)
hg ci -m "Fixed the collision... I hope."
hg co tip
hg update -C tip
According to the guide, this should have removed the case-folding collision and brought the rest of the missing files back, yet another hg status reveals that everything is still missing (!).
Edit: By appending that last command (the update) to the existing commands, I was able to recover the missing files which solved the remainder of the problem.
Note: I had to use the most recent 'problem' version for <bad revision> to fix this problem (that was 160 in my case).
Try
hg update -C tip
That should bring the files back. If not, try reverting everything:
hg revert -r tip -a
Is there a way to get a copy of a hg repository as it was at a particular date?
For example, in subversion I would use:
svn checkout -r {2012-04-04} ...
And it would check out a revision as it appeared on the fourth of April.
In git its a little more complicated, but can be done:
git checkout `git rev-list -n 1 --before="2012-04-04" master`
Can you do the same thing in hg?
(EDIT: My love of revsets has caused me to overlook the obvious answer: hg update --date 2012-04-04 should get you the tipmost revision as of that date.)
If you have the whole repository cloned already (date specifications don't seem to work with clone), you can do
hg update --rev "date('< 2012-04-04')"
If there's a possibility that the repository had multiple heads/branches at the date you want, you'll have to AND in some more conditions to narrow it down to the right changeset:
hg update --rev "date('< 2012-04-04') and branch(v1.1)"
Check out hg help revsets and hg help dates for more information.
Later, if you want to go back to the tip, just
hg update
I've looked for that in the manual, but I can't generate a patch for the last commit.
I tried
hg qnew patch_name
but it does only file with
# HG changeset patch
# Parent a6a8e225d16ff5970a8926ee8d24272a1c099f9c
I also tried
hg export tip
but it doesn't do anything. I committed the changes exactly.
How to generate a patch file with the last commit in?
The command to do this is export:
$ hg export -o FILE -r REV
It doesn't require redirection and will thus work correctly on any platform/shell.
Your hg export tip is the best way to do it, and the hg diff and hg log based answers are just lesser versions of the same. What exactly do you see/get when you type hg export tip? What does the output of hg log -p -r tip show?
The changeset tip is just means "the changeset that most recently arrived in my repository" which isn't as useful a concept as you might think, since hg pull and hg tag all create changesets too. If you really want the last thing you committed you'll need a more precise revspec.
Like so:
hg diff -r tip > tip.patch
You can use this command:
hg log -r tip -p > tip.patch
this will generate a patch for just that revision.
If you want to convert the latest commit to a patch file, use
hg qimport -r tip
This will replace the topmost regular commit with an applied MQ patch file.
To generate patches using "mq extensions" in mercurial, you can follow the below given steps. This will create a patch using mercurial:
1) Enabling mq extensions: Add the following lines to your hgrc file and save it.
[extensions]
mq =
2) Creating a patch using mq extensions: To create a patch using mq extensions you can do the following.
hg qnew -e -m "comment you want to enter" bug_name.patch
In the above command, -e flag is for editing the patch and -m flag is for adding a message to the patch.
3) Updating the patch: For updating the patch, you can use the following command when a patch is already applied.
hg qrefresh
In mercurial is there a way to diff between 2 different tags?
I have tagged my builds and have a couple commits in between builds and want to figure out the differences between the 2 builds.
hg diff -r tag1:tag2
That's all there is to it.
This answer in the Kiln StackExchange seems quite complete (based on hg diff and hg log):
To see all of the changesets that were introduced between, say, the tags v1.0 and v1.1, run:
hg log -r v1.0:v1.1
To see the net sum of differences introduced in those revisions, you'd instead run:
hg diff -r v1.0:v1.1
Mercurial can even format this output in changelog-style, if you want. Simply add the --style changelog parameter:
hg log -r v1.0:v1.1 --style changelog
Given changesets
a
--b
----c
------d
--------e
How can I get a listing of all changesets that come before d. Ie: how can you use hg log to return a-b-c?
Use:
hg log -r "ancestors(d)"
This requires the revsets feature in Mercurial 1.7 and later. See hg help revsets for some great fun.
You can do hg log -r :d (but it will also display d).
hg log -r d::a
or
hg log -r a::d
This will require a reasonably recent (I believe 1.6 or later) version of Mercurial to work.