I run the following hg command and see a whole bunch of revision numbers & their messages fly past my screen, but when it finishes the destination hg repository is empty.
hg convert -s p4 //depot/proj1/... c:\hg\proj1 --config convert.p4.startrev=1267
What am I doing wrong?
When in doubt, use the summary command. You'll probably see something like this:
$ hg sum
parent: -1:000000000000 (no revision checked out)
branch: default
commit: (clean)
update: 15225 new changesets (update)
This says "nothing checked out, on the default branch, nothing to commit, 15225 changesets if you update".
An empty repo looks like this:
$ hg sum
parent: -1:000000000000 tip (empty repository)
branch: default
commit: (clean)
update: (current)
The repository is not empty. There should be an empty directory, .hg, which contains the whole history of your project.
If you want to see the state of your repo at the latest revision, you can update your local copy with hg update.
It turned out my Perforce database had a bit of corruption in very early changesets. Once I told the convert extension to start at a later change set, the conversion went without a hitch.
Related
I am using hg convert to convert a Git repo into Mercurial on a Mac running macOS Mojave.
I've looked at similar questions How to use hg convert properly and hg convert not actually converting? but they haven't provided a definitive answer.
The command I've entered is:
hg convert ./my-src-dir/ my-dest-dir
The output is as follows:
initializing destination my-dest-dir repository
scanning source...
sorting...
converting...
6918 commit comment.
6917 commit comment.
6916 commit comment.
6915 commit comment.
6914 commit comment.
6913 commit comment.
This continues until the most recent commit...
1 commit comment.
0 commit comment.
updating bookmarks
I'm new to Mercurial. I can't see any errors but the destination directory only contains a .hg folder.
The output of hg sum is:
parent: -1:000000000000 (no revision checked out)
branch: default
commit: (clean)
update: 6919 new changesets (update)
phases: 6919 draft
Am I using this command correctly? I'm expecting to see all my src files in the new folder.
The key is:
parent: -1:000000000000 (no revision checked out)
The conversion presumably did work but you haven't yet updated your working folder to any particular changeset. So it appears to be empty.
Not knowing what (if any) branches, bookmarks, etc. are in the repo I can't say exactly what you should update to. But let's say you just want the last revision in there, you could do:
$ cd my-dest-dir
$ hg up tip
to get to whatever it thinks the last one is.
I have a hg respository located in a ~/Server folder on my computer. when I run hg summary from the root of that project, I get the following:
parent: 98:408483c17026 tip
final proposal page set up
branch: GS_Clients
commit: 6 deleted (clean)
update: (current)
So I wanted to make a backup copy of this project in my dropbox folder, so I ran :
hg clone <current_source> ~/Dropbox/Repositories/<new_source>
yet when I run hg summary in the new directory, is states that it is at revision 0:
parent: 0:b03c2c025c61
inital commit
branch: default
commit: (clean)
update: (current)
I've tried all manners of pushing,pulling and updating, but I can't get the new repo up to date.
How can I make a clone that is up to date, and/or how can I get this repo up to date.
Your first summary is on branch GS_Clients, while the second one, because it is a fresh clone, is on the default branch. Try hg update GS_Clients.
The update: (current) line only means you're at a head of the current branch.
I figure only rev 0 is on the default branch, and all your other commits are on GS_Clients or other named branches. Commands like log, glog, and UIs like TortoiseHg would have made that pretty obvious, where summary does not.
If I create a new branch using hg:
$ hg branch newbranch
And then look at branches:
$ hg branches
default 194:d9df55198e53
newbranch 193:a36a491b8507 (inactive)
newbranch is marked as (inactive), despite my working directly being currently mapped to it.
If I do a commit, default will then be flagged (inactive).
However, if I switch to default, merge, and commit, then switch back to newbranch, newbranch will say (inactive) again.
This is a bit of a pain, because I may do that on a friday night, and not come back to it until Monday, and not know what branch my working directory is actually pointed at.
So, is there a better way to tell, or should I always make it my workflow to specify the branch I want to work in before I start.
Though hg summary will tell you what branch you're on, so will hg branch without a branch name argument. Let's say I've never created a branch called mybranch before, but I want to start it:
> hg branch
default
> hg branch mybranch
marked working directory as branch mybranch
And now I've worked for a bit and want to commit, but forgot if I set the branch name for this next commit or not:
> hg branch
mybranch
Oh, I did.
Ok, I just discovered hg sum:
$ hg sum
parent: 195:d0a2617b4b51 tip
[Commit Message]
branch: newbranch
commit: (clean)
update: (current)
So I guess this is how you do it?
I'm trying to get the hg-git extension working under Windows and after hours of fiddling, I finally seem to have it working. However, nothing shows up in my git repository even though the output of hg push reads:
importing Hg objects into Git
creating and sending data
github::refs/heads/master => GIT:8d946209
[command completed successfully Wed Oct 20 15:26:47 2010]
Try issuing the command hg bookmark -f master
(use -f to force an existing bookmark to move)
Then try pushing again.
This works because Hg-Git pushes your bookmarks up to the Git server as branches and will pull Git branches down and set them up as bookmarks. (from the official README.md)
And it seems that just after I asked this, I made a trivial change. This was picked up and pushed. So it seems that you have to wait until you've made a new commit in order for hg-git to pick it up.
I had chosen to 'Initialize this repository with a README'. This meant I ended up with two heads, which I couldn't hg merge because one had a bookmark.
To get pushing working, I had to:
configure hg-git and github remote as per https://blog.glyphobet.net/essay/2029
pull from github and update
force the merge (checking which id to use with hg heads),
commit the merge
add a trivial change to a file (add a space char to the end),
commit, then
move the bookmark to the tip
push to my configured github remote
This ended up with commands as follows (substituting in <x> sections)
hg pull github
hg update
hg merge <revision-id-of-incoming-git-version>
hg addremove
hg commit -m 'merged with github'
# make some trivial change to a file - eg add a space where it doesn't cause harm
hg add <changed-file>
hg commit -m 'trivial change'
hg bookmark -f master
hg push github
make sure you pick the remote revision for the merge above - if you don't it doesn't work!
So I keep making a silly mistake in Mercurial. Often times, I'll start work without doing an "hg pull" and an "hg update." When I try to push my changes, I get an error.
Is there any way to delete my local commits so I can avoid creating multiple heads, branches, etc? I just want to delete my local commits, merge my changes with the tip, and then re-commit. Sounds simple, right? I can't seem to find any way to easily delete local commits so I can cleanly merge with the tip.
Again, I'm only trying to delete local commits made with "hg ci". I don't want to modify files, revert, etc.
Enable the "strip" extension and type the following:
hg strip #changeset# --keep
Where #changeset# is the hash for the changeset you want to remove. This will remove the said changeset including changesets that descend from it and will leave your working directory untouched. If you wish to also revert your committed code changes remove the --keep option.
For more information, check the Strip Extension.
If you get "unkown command 'strip'" you may need to enable it. To do so find the .hgrc or Mercurial.ini file and add the following to it:
[extensions]
strip =
Note that (as Juozas mentioned in his comment) having multiple heads is normal workflow in Mercurial. You should not use the strip command to battle that. Instead, you should merge your head with the incoming head, resolve any conflicts, test, and then push.
The strip command is useful when you really want to get rid of changesets that pollute the branch. In fact, if you're in this question's situation and you want to completely remove all "draft" change sets permanently, check out the top answer, which basically suggests doing:
hg strip 'roots(outgoing())'
If you are using Hg Tortoise just activate the extension "strip" in:
File/Settings/Extensions/
Select strip
Then select the bottom revision from where you want to start striping, by doing right click on it, and selecting:
Modify history
Strip
Just like this:
In this example it will erase from the 19th revision to the last one commited(22).
Modern answer (only relevant after Mercurial 2.1):
Use Phases and mark the revision(s) that you don't want to share as secret (private). That way when you push they won't get sent.
In TortoiseHG you can right click on a commit to change its phase.
Also: You can also use the extension "rebase" to move your local commits to the head of the shared repository after you pull.
As everyone else is pointing out you should probably just pull and then merge the heads, but if you really want to get rid of your commits without any of the EditingHistory tools then you can just hg clone -r your repo to get all but those changes.
This doesn't delete them from the original repository, but it creates a new clone that doesn't have them. Then you can delete the repo you modified (if you'd like).
I came across this problem too. I made 2 commit and wanted to rollback and delete both commits.
$ hg rollback
But hg rollback just rolls back to the last commit, not the 2 commits. At that time I did not realize this and I changed the code.
When I found hg rollback had just rolled back one commit, I found I could use hg strip #changeset#. So, I used hg log -l 10 to find the latest 10 commits and get the right changeset I wanted to strip.
$ hg log -l 10
changeset: 2499:81a7a8f7a5cd
branch: component_engine
tag: tip
user: myname<myname#email.com>
date: Fri Aug 14 12:22:02 2015 +0800
summary: get runs from sandbox
changeset: 2498:9e3e1de76127
branch: component_engine
user: other_user_name<name#email.com>
date: Mon Aug 03 09:50:18 2015 +0800
summary: Set current destination to a copy incoming exchange
......
$ hg strip 2499
abort: local changes found
What does abort: local changes found mean? It means that hg found changes to the code that haven't been committed yet. So, to solve this, you should hg diff to save the code you have changed and hg revert and hg strip #changeset#. Just like this:
$ hg diff > /PATH/TO/SAVE/YOUR/DIFF/FILE/my.diff
$ hg revert file_you_have_changed
$ hg strip #changeset#
After you have done the above, you can patch the diff file and your code can be added back to your project.
$ patch -p1 < /PATH/TO/SAVE/YOUR/DIFF/FILE/my.diff
You can get around this even more easily with the Rebase extension, just use hg pull --rebase and your commits are automatically re-comitted to the pulled revision, avoiding the branching issue.
hg strip is what you are looking for. It's analogous of git reset if you familiar with git.
Use console:
You need to know the revision number. hg log -l 10. This command shows the last 10 commits. Find commit you are looking for. You need 4 digit number from changeset line changeset: 5888:ba6205914681
Then hg strip -r 5888 --keep. This removes the record of the commit but keeps all files modified and then you could recommit them.
(if you want to delete files to just remove --keep hg strip -r 5888
If you are familiar with git you'll be happy to use histedit that works like git rebase -i.
[Hg Tortoise 4.6.1]
If it's recent action, you can use "Rollback/Undo" action (Ctrl+U).
In addition to Samaursa's excelent answer, you can use the evolve extension's prune as a safe and recoverable version of strip that will allow you to go back in case you do anything wrong.
I have these alias on my .hgrc:
# Prunes all draft changesets on the current repository
reset-tree = prune -r "outgoing() and not obsolete()"
# *STRIPS* all draft changesets on current repository. This deletes history.
force-reset-tree = strip 'roots(outgoing())'
Note that prune also has --keep, just like strip, to keep the working directory intact allowing you to recommit the files.