This is an extension of the following question:
Mercurial show number of commits ahead of "origin"
I want to find out the number of commits yet to be pushed to the remote repository without contacting the remote (So that I can add it to my prompt).
In git I can do that with:
git rev-list branchname#{upstream}..HEAD | wc -l //I am counting the number of lines to get the number of commits by which i am ahead.
The original answer advices to use:
hg summary --remote
But this contacts the remote repository and takes quite sometime, so putting it in prompt seems a bad idea.
Does anyone know if mercurial allows to do this, since the original question is quite outdated, i thought some new method or extension might have come up.
hg outgoing : log of everything that has yet to be pushed (but it does contact the remote repository)
hg log -r "draft()" : log all of the commits that are in draft phase in your repository (without contacting remote). This doesn't definitively mean that they are not in the remote repo, but it's very close.
You can use --template templates to customize the output.
Hope this helps.
Related
According to Mercurial's help page, hg incoming (and the "check for incoming changes" button in tortoiseHG does:
"Show new changesets found in the specified path/URL or the default
pull location. These are the changesets that would have been pulled by
'hg pull' at the time you issued this command."
My question is: What is the point of this behavior? In what situation would I want to not just pull? If I wanted to see what changesets were pulled, I could just look at the log.
Have I been using mercurial wrong my whole life?
There are various scenarios in which it can be useful. I'm just listing down my use cases hre.
a) I do hg incom to make sure I can pull and get ready to rebase my commits if there is anything on the remote.
b) I use hg log -G followed by hg incom quite often when doing offline peer review to make sure I don't pollute my repo and to know which rev to strip (if required) after the pull. FWIW, as a result of hg incom I have asked people to change their commit message even without pulling their changes for review.
Consider the following situation:
$ md repo1; cd repo1
$ echo some data > myfile
$ hg init; hg addremove; hg commit -m "First commit."
adding myfile
myfile
committed changeset 0:32c7aa047f3b
$ hg serve
listening at http://vostro.rath.org:8000/ (bound to *:8000)
And then in another terminal:
$ hg clone http://vostro.rath.org:8000/ repo2
requesting all changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
updating to branch default
resolving manifests
getting myfile
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ cd repo2; hg phase tip
0: public
..and in the first terminal again:
127.0.0.1 - - [25/May/2013 16:38:40] "GET /?cmd=listkeys HTTP/1.1" 200 - x-hgarg-1:namespace=bookmarks
^Cinterrupted!
$ hg phase tip
0: draft
To me this looks very wrong. Someone just pulled the changeset from the first repository, so it is obviously public. However, it still appears as "draft" in the repository.
Can someone explain the rationale for this behavior? As the owner of the first repository, I would very much like to know when someone has pulled a revision (so that e.g. I don't rebase it anymore), so I think it would be sensible if the hg server process would update the phase accordingly.
You will probably get a better answer on the mailing list for this, but my understanding is this:
hg pull has always been a read-only command and can be run without write access to the remote repository. Changing the phase in the remote repository would (obviously) require a write. On the other hand, hg push has always written to the remote repository, and so phases introduced no change.
Changing hg pull from read-only to read-write could cause some people's work flows to break, and that's a mortal sin in mercurial development. (E.g. An anonymous user pulling from a public server, sending back changes via e-mail bundles)
Basically it's a historical quirk because phases are a retro-fit.
The hole this leaves open is that the original owner of the change-set could amend it, without realising that the change has already gone into the wild. I expect that this hole hasn't worried too many people because the "change-set evolution" features that are being developed solve the problem in a better way.
I tend to think of the phases as:
Public - Publicly visible and immutable
Draft - Publicly visible and mutable
Secret - Not publicly visible and mutable
I think draft is only there because that's basically where we were before phases were added, and is a bit of a weak concept. Really, if your working in an environment where people may pull directly from you, then I suggest working more with public and secret phases, and avoid draft.
As #zerkms said, pull isn't intended to change the remote repository.
If your working repository is being used as a server, you have a few options:
Set the default of commits to "public" instead of "draft". Others can pull at any time so just assume they are public.
Set the default of commits to "secret". Others won't be able to pull them. Set them to "public" when you are ready to share.
Set your repository as "non-publishing". Others can pull your draft changesets, but they will still be marked as "draft".
Here's how to specify these behaviors in mercurial.ini/hgrc.
[phases]
publish = False
new-commit = public
pull isn't intended to change the remote repository phase but the phase of your local repository.
And to be clear - you shouldn't care what phase is in the remote repository.
And even more - remote repository may be hosted using old mercurial version which doesn't support phases.
Why this behavior?
Because phases are only make sense for the local repository and made to help preventing history modification mistakes.
When I type hg outgoing, I get a response like this:
comparing with ssh://server:1234/path/to/repo
and a delay while it communicates over the network.
Why is this network traffic necessary? Is there something fundamental about Mercurial which means it can't remember which commits have been pushed, and which haven't?
Is there an alternative command which can give me similar information without having to communicate over the network?
As Mercurial is a distributed system, there are multiple ways for your changes to get from your local repo to the remote repo.
For example:
it is possible for someone to pull changes from you and then push those changes to the remote repo
you could actually just copy your local repo using whatever operating system you have and Mercurial would be totally unaware of that. You could then push the changes in this copy to the remote repo.
However, if you have Mercurial 2.1 or later you can use hg phase to determine which changesets have been pushed. Assuming you don't use hg phase to change the status of any changesets then the changesets with a phase of draft or secret have not been pushed and those with a phase of public have. Use
$ hg log -r "not public()"
to see unpublished changesets.
It won't catch the two examples I gave above but it will probably be good enough if you just want to know which changesets you have not pushed.
Look here or check hg help phases for instructions on how to work with phases.
A mercurial repository can potentially connect with multiple other repositories. So, I guess it needs to make sure the changes that weren't pushed from your repository, didn't arrive from another repository already.
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'm a VERY happy user of bitbucket and mercurial after years of putting up with subversion (and CVS, SourceSafe and others; anybody remember SCCS?). I've considerable project history now in my local hg repo, pushed daily to bitbucket and thence to my home machines.
Problem is, my company wants me to maintain a copy of this history in subversion. And I've hit a stone wall trying to set this up. I've installed hgsubversion, I think correctly. And I've used svnadmin to create an empty svn repository ready to hold the hg history.
But now what? The instructions say to start by pulling a clone (of nose? what's that? I assume this means checkout a copy of the new empty svn directory. OK did that.
But now what? I assume the next step is to push my real local hg clone to the empty svn repo I just checked out. But nothing I've tried will do this. Pull fails as follows, reporting "unrelated repository" (as I recall I gate it the URL of my master local hg repo to get around the "Needs a URL" popup on everything else I've tried.
found new changeset 139d02f4b233
examining 4e97a23b6815:342df9e52cec
abort: repository is unrelated
[command returned code 255 Mon Apr 25 11:29:33 2011]
The result of all this fumbling around is a directory with .hg, .svn and .hgignore entries and nothing else.
So, I feel I'm missing something basic that hundreds of others must have tried by now. Can someone please help me get started? Thanks!
PS: Currently the intent is to maintain SVN permanently as the team repo and push changes there from Hg periodically which would remain the main client for me indefinitely. In case this matters...
You can use the convert extension:
hg convert --dest-type svn mercurialrepo svnrepo
And hgsubversion allows you keep both of them in sync ( bidirectional)
Answered here at SO already:
Converting from Mercurial to Subversion
Migrating from Mercurial to Subversion
Perhaps look at the answers to this question.
Hgsubversion is for working with a repository cloned from SVN using Hg, not the other way around.