I have a project that I want to push to a Mercurial repository on Google Code.
I initialized a Mercurial project locally and checked in the code locally.
The only instructions I can find on the Google Code repository are for cloning:
hg clone https://blahblah.googlecode.com/hg/ blahblah
But I assumed that pushing should be similar.
So I tried:
hg push https://blahblah.googlecode.com/hg/ blahblah
But I got an error saying "invalid arguments".
One of the options it provides is "force push". Is this what I need?
If you are trying to push back a repository that you cloned, try
hg push
otherwise try
hg push https://blahblah.googlecode.com/hg/
For future reference, here's the usage information from Mercurial's built-in help system:
$ hg help clone
hg clone [OPTION]... SOURCE [DEST]
$ hg help push
hg push [-f] [-r REV]... [-e CMD] [--remotecmd CMD] [DEST]
I think the reason hg push is failing is because you're giving it too many arguments.
Try the 'force'. Force says "and you're allowed to create new remote heads". You google code has no changesets, so no heads, so you're going from zero to one. I still wouldn't expect that 'force' is required, but it's definitely worth the try.
Most people starting a repo from scratch would have cloned the empty repo from google (or bitbucket) first, and then made their changes, and then pushed. I think this is what las3rjock thought you did.
Related
We have a code review repository where people hg push -f all sorts of stuff. After reviews are complete, we pull from the project's central repository, rebase, and push. I recently upgraded to mercurial 2.1 and get this message:
abort: can't rebase immutable changeset 43ab8134e7af
(see hg help phases for details)
when I try to hg pull --rebase from the central repository. How do I fix it?
In the review repository's .hg/hgrc file, add these lines:
[phases]
publish = False
The problem is due to a new feature in mercurial 2.1 called phases. It's great. Here is a nice introduction to its use.
To make the changesets in question mutable right now, use hg phase -f -d REV to force REV to be mutable again. Once the hgrc file has been changed, you shouldn't have to do that any more.
As a side note, hg push -f is lame. Make an alias hg review that pushes with -f to that repository.
I don't think disabling phase support on the server is the correct solution, but your problem sounds weird.
Pull --rebase should rebase your local changes, on top of the remote changes, which should be allowed, even if phases are supported by the client, as long as these changes have not been seen by anyone else, eg. they haven't been pushed out anywhere.
Is it possible that you have already pushed your your own changes, to somewhere else (which set them to public phase), and after that tried pulling from the testing repo? Because then, this is the correct behaviour that you are seeing.
Most of the time it is a bad idea to mess with phases manually (with hg phase -f), because it can easily lead to a history rewrite, which can lead to duplicated changesets, or various errors when other people try to pull/push. If a changeset became marked as public (as in your case), it probably happened for a good reason.
I've encountered such behaviour with collapsed rebase. Phasing out back to draft hadn't helped me. So I've just pulled up (hg pull -u) to sync with remote repo, then just grafted the problem commit (hg graft <problem_commit>) and then amended this very new commit.
I have been happily using HgSubversion for awhile and today I forgot to add the --svn to the rebase command.
Now i get the dreaded unknown revision ''
Is there a way to recover from this?
You should be able to do "hg svn rebuildmeta" and then do "hg pull" and have it repair things.
Note: this is untested, so I'd work on a duplicate of the local repo in case it screws things up. My memory of the code suggests this will work.
I'd try using the transplant extension to fix this:
Re-clone the SVN repository to a new local repository.
Examine the history of the original repository and note which changes need moving
Transplant the changes from the old repository to the new repository
For example - fixing an hgsubversion repo called project:
> hg clone svn+http://svnrepo/project project-tmp
Then examine the log of your original project folder and do the following from the project-tmp folder:
> hg transplant -s ../project 1234
Where 1234 is the revision that you want to move over. Repeat this until all your revisions are copied.
When you're done you should be able to start using the new folder in place of the old folder by re-pulling from SVN, rebasing your changes and push them back (don't forget --svn)
I've just started with Mercurial, I have a 'central' repository on Bitbucket which I cloned onto one machine and made changes and committed and pushed. I then cloned from Bitbucket to another machine committed and pushed which was fine. I then came back to the first machine, made changes committed and attempted to push, but got the error message. What am I doing wrong? Should I have pulled first? How can I resolve the error and push? Any help is appreciated!
Darren.
A Mercurial repository gets its identity when you make the first commit in it. When you create a new repository on Bitbucket, you create an empty repository with no identity.
When you clone this repository to machine A and make a commit and push it back, then you brand the repository. If you have cloned the repository on the second machine before pushing from the first, then you can end up in the situation you describe.
Please run hg paths on the machine where you cannot push. Then make a separate clone of the repository it says it will push to. Now examine the first changeset in each repository with
hg log -r 0
If the initial changesets are different, then you have two unrelated repositories, as we call it in Mercurial. You can then export the changes you cannot push as patches and import them in the other.
If you're pretty sure the push path is correct, it may be worth it to just export your changes to patches from the problem repo, clone again from Bitbucket and then import the patches into the new repo. This will either just work or reveal a bad/corrupted commit.
I would like to share knowledge about Mercurial internals.
Repositories unrelated when they have no any same revisions.
Corresponding piece you can find in mercurial/treediscovery.py:
base = list(base)
if base == [nullid]:
if force:
repo.ui.warn(_("warning: repository is unrelated\n"))
else:
raise util.Abort(_("repository is unrelated"))
base is a list of roots of common parts in both local/remote repositories.
You always may know how repositories are different by:
$ hg in $REMOTE
$ hg out $REMOTE
You always may checks roots of both (after cloning both locally):
$ hg -R $ONE log -r "roots(all())"
$ hg -R $TWO log -r "roots(all())"
if output from above commands doesn't share IDs - those repositories are unrelated. Due to hash properties it is very impossible that roots be equal accidentally. You may not trick roots checking by carefully crafting repositories because building two repositories looks like these (with common parts but different roots):
0 <--- SHA-256-XXX <--- SHA-256-YYY <--- SHA-256-ZZZ
0 <--- SHA-256-YYY <--- SHA-256-ZZZ
impossible because that mean you reverse SHA-256 as each subsequent hash depends on previous values.
Having this info I believe any Devs be able to troubleshoot error: repository is unrelated.
See also Mercurial repository identification
Thanks for attention, good hacking!
You get this message when you try to push to a repository other than the one that you cloned. Double-check the address of the push, or the default path, if you're just using hg push by itself.
To check the default path, you can use hg showconfig | grep ^paths\.default (or just hg showconfig and look for the line that starts paths.default=).
I want to completely delete a Mercurial commit as if it was never entered in the repository and move back to my prior commit.
Is this possible?
If it was your last commit and you haven't pushed it anywhere, you can do that with rollback. Otherwise, no. Not really. Time to change your passwords.
Edit: It has been pointed out that you can clone from an older revision and merge in the changes you want to keep. That's also true, unless you have pushed it to a repo you don't control. Once you push, your data is very likely to be very hard to get back.
You can try to remove mq info about your commit.
For this you need to go File->Settings->Extensions.
There check mq and restart gui.
After that just right click on unneeded commit and
ModifyHistory->Strip
To edit the history I would use the Histedit Extension extension.
hg histedit 45:c3a3a271d11c
However keep in mind this only makes sense in a situation where you have not yet pushed the commits to the public repository, you own the public repository and/or you can account for all the clones out there. If you receive the following error:
abort: can't rebase immutable changeset 43ab8134e7af
It means that Mecurial thinks this is a public changeset (see phases) that has already been pushed - you can force it to be a draft again doing:
hg phase -f -d 45:c3a3a271d11c
I encounter this fairly often. I make a commit and then pull to push. But then there is something incoming that makes my newly made commit unnecessary. A plain hg rollback isn't enough because it only undoes the pull...
This is the thing to do:
hg strip <rev>
Things are painless when you don't push your changesets anywhere.
If it's more than one commit and/or you already pushed it somewhere else, you can clone your repository and specify the last changeset that should be cloned.
See my answer here how to do this:
Mercurial: Fix a borked history
If you only committed locally and didn't push, you can just create a clone locally (as described in my link) and you're done.
If you already pushed to some remote repository, you would have to replace that with your clone.
Of course it depends if you are able (or allowed) to do this.
You can use "hg backout" to do a reverse merge basically. All options are discussed in the freely available book "Mercurial: The Definitive Guide":
http://hgbook.red-bean.com/read/finding-and-fixing-mistakes.html
If using tortoise you can use modify history > strip...
Yes. Unless I am mistaken, as of v2.3 (rel. 2012/08/01) you can use the HisteditExtension with a drop command to drop a commit, along with strip or backout to remove changes.
A simple Google search on the feature: https://www.google.com/webhp#q=histedit+drop
In 2022 I do use evolve extension. It is one of the best extensions for this purpose.
To prune unwanted changeset, if you for example did a quick hack to get the code working:
$ echo 'debug hack' >> file1.c
$ hg commit -m 'debug hack'
Now you have a proper patch you can do hg prune .:
$ hg prune .
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
working directory is now at 2a39221aaebb
1 changesets pruned
If you push the change to the remote repository you will find only obsolescence markers:
$ hg push
searching for changes
no changes found
remote: 1 new obsolescence markers
To check the changes to your local repo you can pull from the remote one:
$ hg pull
pulling from ssh://userid#server/repo
searching for changes
no changes found
I have started a Mercurial based project on google code.
I have worked in subversion for sometime, but I am confused with what to do what in Hg.
I would like help on the following:
How do I initialize project (first on my local machine) (then from my local copy to google's server)
How do I get my copy of a build from the server
How do I update(merge/sync) my local changes back to the server
My project is in PHP and I am using netbeans
Both barkmadley and RC touch on it, but what you're explicitly missing is that your order is wrong in step one. Create the empty repo on google, clone it to local, and then commit locally and push. Don't try to create it locally and then push to google. There's nothing inherently wrong with the idea of doing it that way, but it's not the workflow for which google is set up.
For what it's worth, I wrote a blog post about Managing a Google Code project with Mercurial
Here's some infos:
For #1: initialize the project on google-code, then clone the repository locally (hg clone ...), add you files to the directory created by the clone process and commit that (hg commit -m 'your message' then push (hg push).
For #2: see #1
For #3: to update you local copy (hg pull -u) and to commit your change hg commit followed by hg push
As mentioned by barkmadley, Hg Book is worth reading
Hg Book should help.
when you create a project you can select the version control system used.
from there you should be able to get hg clone instructions from google code on the downloads tab.
this will give you an initial checkout of the system. Then you copy your work into it, and hg push and hg pull to sync between the google repository. To save changesets to your local copy use hg commit
Try reading this user contributed wiki. It is quite straigtforward I reckon.