I've forked a Mercurial repository, and now I want to pull the changes from the main repository into my fork. If this were git, I would do something like...
git remote add upstream <url>
git pull upstream master
How do I do this sort of thing in Mercurial?
You could also modify your hgrc file in your repo
default = ssh://hg#bitbucket.org/<my_user>/<my_repo>
upstream = ssh://hg#bitbucket.org/<other_user>/<other_repo>
Then you can do
hg pull upstream
If you cloned the repository from the one you want to pull changes from, you can simply do:
hg pull
If you cloned the repository from another repository, you can:
hg pull <location of repository to pull from>
You'll then need to update your working copy:
hg update
That's the basics, anyway. More details are available in the Mercurial: The Definitive Guide
Have you tried the pull command?
hg pull http://master.com/master
If that does not work, please elaborate.
You could also modify your hgrc file in your repo to use the special path names default and default-push.
default-push = ssh://hg#bitbucket.org/<my_user>/<my_repo>
default = ssh://hg#bitbucket.org/<other_user>/<other_repo>
Then you can pull from upstream (aka default) with
hg pull
and push to fork (aka default-push) with
hg push
Related
I cloned an hg repo and created a feature branch (via hg branch myfeature). I have staged & committed changes to it via hg add . and then subsequently hg commit -m "My new feature branch.".
I would now like to push those changes (in the branch; not as default) to the remote server (where I cloned the project from) so that other devs can code review the changes in the myfeature branch.
I found a blog that recommends using:
hg push --create-branch-remote
But this isn't working for me - any ideas where I'm going awry?
You forgot to read hg help push for your version of Mercurial
...
--new-branch allow pushing a new branch
...
Looks like --new-branch is what I wanted.
I have a dependancy as a subrepository (without write access to) in my project.
I'd like to add a few personal customizations to that subrepository - possibly using mq.
I also would love to be able to just clone the main repo to build it. Currently I have to:
clone the repo - with subrepositories getting cloned automagically
manually clone all the patchqueues for subrepositories
How do I get rid of step 2? Is it even possible without an outside script? (I'm using bitbucket if it makes any difference).
One notion is to make the subrepo not the repo to which you have no write access, but a clone of your own based on their repo.
cd myclones
hg clone http://notmydomain.com/their-repo my-clone-of-their-repo
and in your project's .hg/hgrc you use a [subpaths] section to map their URL to your local clone:
[subpaths]
http://notmydomain.com/their-repo = ../my-clone-of-their-repo
Then you end up with your repo using your local (read-write) clone of their repo to which you otherwise have read-only access. This has a few benefits:
faster -- you're only checking local repositories for all actions
writeable -- you can edit directoy in myproject/their-repo and commit and push (to your local clone)
And when you want to merge in their upstream changes you just go into ../my-clone-of-their-repo and hg pull and hg merge their updates into your customizations.
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'm starting with Mercurial. I'm reading the mercurial book but still have a question.
I've started my project month ago, and i have a lot of files and directories in it. Now, i want to use Mercurial and made myself an account in bitbucket. Now, i want to set this project up in Bitbucket. How can i add all those files to the bitbucket repo?
This is what i was thinking i could do:
I could try to (1) clone the empty repo (from bitbucket) (1) copy all files into that directory, (3) issue an "hg add" and after that (4) commiting.
Maybe you have a better way to do this.
Thanks!
(1)
hg clone https://ME#bitbucket.org/ME/myproject
(2)
cp existing-project/* myproject/
cd myproject
(3)
hg add
(4)
hg commit -u ME
(5)
hg push (i think i have to do this to make the changes visible)
You can simply hg init, hg add, and hg commit in the original project folder, then edit ~/project/.hg/hgrc to add a default-push location of your bitbucket repo (you can clone it to a temporary folder to get the hgrc created for you which you can copy into your project, even, without needing to RTFM for the right syntax.)
Because of the distributed nature of mercurial, this hgrc entry is the only thing relating your local repo to bitbucket at all; you can even hg push https://ME#bitbucket.org/ME/myproject without making the link explicit anywhere. Each copy of a repository is completely self-sufficient.
Wooble's answer is ok, but it's missing something, so I'm supplementing here.
When you first create an empty repository (by hg init or creating on bitbucket), it has no identity. However, as soon as it has any changesets, it has an identity and you can only push/pull between it and repositories that share that identity.
If you had 2 repositories A and B for separate projects, you wouldn't be able push/pull between them. Once you create a new repository on bitbucket you can push changesets from either A or B to that repo once. If you push changes from B that first time, the bitbucket repository is now related to B. You can't then push changesets from A into it, or pull changesets into A from it.
So when Wooble says,
...this hgrc entry is the only thing relating your local repo to bitbucket at all;
That is correct while it is still empty as it is not related to any repositories until it has changesets. And you still need that address to be able to push/pull between your local repo and the bitbucket repo, but once you've pushed changesets to it it also has that identity that relates it to your local repo.
I am looking for best practices to do the following:
When I need to implement a feature or fix a bug, I am creating new Mercurial repository from the main one (a trunk).
Then, within some days, or weeks, I am implementing the task in newly created repository, making commits and periodically merging with trunk. After the code in new repository will pass all code reviews, I should provide a repository with all changes collapsed into single revision.
My common way to do this (rdiff extension should be enabled):
hg clone ~/repos/trunk ~/repos/new-collapsed
cd ~/repos/new-collapsed
hg diff ~/repos/new > new.diff
patch -p1 < new.diff
hg commit
This works almost well except when there are binary files present in the changes from ~/repos/new. Another way could be:
hg clone ~/repos/trunk ~/repos/new-collapsed
cd ~/repos/new-collapsed
hg pull ~/repos/new
hg update
hg rollback
then resolve possible conflicts and manually commit the changes
Both ways look for me somewhat ugly and non-native, so I am looking how this operation could be simplified. I've played with rebase extension, but seems its hg rebase --collapse command does not work with workflow described above.
Any ideas are welcome.
Sounds like a good case for mercurial queues.
I do something similar with the histedit extension.
My workflow is something like:
clone a central repo
commit incremental changes to local repo
clone my local repo to make collapsed repo
hg histedit and select/discard/fold the revisions as needed
hg push the collapsed repo to central repo
pull central repo to local or refresh local from scratch
I ensure that my local repo never gets pushed to the central repo by adding an invalid default-push path to the .hg/hgrc file in the local repo root directory.
Solved: Just add
[diff]
git = True
to your hgrc file, and then use my first solution with rdiff extension, replacing patch with hg import:
hg clone ~/repos/trunk ~/repos/new-collapsed
cd ~/repos/new-collapsed
hg diff ~/repos/new > new.diff
hg import new.diff
hg commit