How to "push" manually?

[Peter Hosey]

On Apr 05, 2009, at 18:56:11, skip at pobox.com wrote:
> I tried "hg push -r82" just now but nothing updated.

Well, yeah. It's already there. :-)

Moreover, push only ever copies commits. It does not strip commits.

> Now I have this revision (20939e395812) on my webserver, but not the  
> entire history of that head.

Actually, you do (did) have the entire line of history on the server.  
Every commit includes a reference to its parent; a commit can't exist  
if its parent is missing.

You can type (could have typed) hg log -r 0e57ad532602:null to see  
that head and all of its ancestors all the way back to the beginning  
of history. (To shorten that log, you could specify a closer ancestor,  
such as the aforementioned X, in place of null, or use --limit or a  
pager.)

> How do I revert the first push?

There's no “hg unpush” or anything like that, but you could ssh  
into the server, enable the mq extension, and strip the first commit  
after X in his line of history.

> (Never mind.  After a false start I started from scratch on my web  
> server.  I think I have it corrected now.)

If you simply cloned your local repository, you probably re-copied his  
patches to the server repository, unless you stripped his patches  
locally first.

> I wanted to "import" [Ben's changegroup bundle] simply so I could  
> work with it.  …  I believe now that I should have probably  
> imported his .hg file into an entirely new repository.

That's one way. Another would be to use mq—this time for its intended  
purpose, which is maintaining a patch queue.

First, whether you use mq or not, you should have contributors send  
you patch files instead of changegroup bundles. A contributor would  
create such a file using hg export instead of hg bundle, and you  
(without mq) would use hg import instead of hg unbundle. The  
difference is that a patch file is clear text with a unified diff— 
easily readable in any text editor.

Then, with mq, you'd use the qimport command to add each of his  
patches as a patch in your queue. You could then unapply (qpop) and  
reapply (qpush) the patches as you work on other things. When you're  
satisfied with the patches, you'd qpush them (if necessary) and then  
qfinish them; the latter step takes them out of the queue and makes  
them permanent commits.

As usual, the wiki has more info:

	http://www.selenic.com/mercurial/wiki/index.cgi/MqExtension

as does the book:

	http://hgbook.red-bean.com/read/managing-change-with-mercurial-queues.html