How to "push" manually?

[Peter Hosey]

On Apr 05, 2009, at 17:01:31, skip at pobox.com wrote:
>>> Apparently so. You have one or more heads in your local repository
>>> that the remote repository doesn't.  If you pushed everything, the
>>> remote repository would have heads that it previously didn't. That's
>>> 1r|creating remote heads1r}.
>
> I don't get it.  Is a Mercurial head like a branch?

A head is the last commit on a line of history. The difference is that  
a head is one commit, whereas a line of history is a series of one or  
more commits.

Sometimes, people call lines of history “branches”, but I prefer to  
reserve that word for *named* branches—those that you explicitly  
create with the hg branch command.

> I did incorporate some changes another guy made available for me a  
> week or two ago (some sort of blah.hg file).  From my bash history:
>
>    hg pull ~/tmp/lockfile.pidlockfile.r76.hg
>
> I recall having trouble after that as well.  (Look back through the  
> list archives.)
>
> ⋮
>
> Working from clues in your email, I executed hg heads:
>
>    % hg heads
>    changeset:   82:20939e395812
>    tag:         tip
>    user:        Skip Montanaro <skip at pobox.com>
>    date:        Sun Apr 05 14:43:05 2009 -0500
>    summary:     a couple more python 2/3 diffs
>
>    changeset:   78:0e57ad532602
>    user:        Ben Finney <ben+python at benfinney.id.au>
>    date:        Wed Mar 11 20:56:17 2009 +1100
>    summary:     Test and implement PIDLockFile.read_pid().

Ben Finney's changes are the second line of history. The revision he  
started working on is the common ancestor of his line and your line—X  
in the graph I showed you.

(BTW: I speak of “his/your line of history”, but there is no reason  
that these lines couldn't each have changes from both of you. A line  
of history is just a chain of commits, nothing more.)

If you decide to integrate his changes into your main line, you'll  
merge them.

If you decide to abandon his changes:

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

> Then over on my web server:
>
>    $ hg heads
>    changeset:   82:20939e395812
>    tag:         tip
>    user:        Skip Montanaro <skip at pobox.com>
>    date:        Sun Apr 05 14:43:05 2009 -0500
>    summary:     a couple more python 2/3 diffs
>
>    changeset:   78:0e57ad532602
>    user:        Ben Finney <ben+python at benfinney.id.au>
>    date:        Wed Mar 11 20:56:17 2009 +1100
>    summary:     Test and implement PIDLockFile.read_pid().

Sounds like you went ahead with that push -f, then.

> I want the changeset from Ben Finney in my local repository, but not  
> on my web server.  Going back to my original attempt to push, should  
> I have explicitly just pushed rev/changeset 82:20939e395812?

Yes. You would have typed “hg push -r82”.

(“82:20939e395812” is two revision identifiers, not one. One is the  
commit's repository-local serial number, which is the decimal number  
“82”; the other is its revision identifier, which is the  
hexadecimal number “20939e395812”.)

>>> Is there not a simple Mercurial cheat sheet somewhere?
>
>>
>> What good is knowing commands without understanding the concepts  
>> behind them?
>
> Ok.  Is there not a simple Mercurial concept sheet somewhere?

You might try this:

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

There's also the hg book, but that's obviously more book than sheet:

	http://hgbook.red-bean.com/

> How do I find out what other extensions came with Mercurial but are  
> disabled by default?


Look in the hgext directory, either in the Mercurial source tree or in  
your Python site-packages directory.

> Is there a common set of "unbelievably handy" extensions the  
> Mercurial aficianados always enable?

Yes, but they're generally disabled by default for various good  
reasons (changes core behavior, enables mutable history, significant  
delay to hg loading, etc.):

- graphlog
- mq (mutable history)
- record
- patchbomb (easy to annoy people with)
- alias (enables changing core behavior)
- rebase (mutable history)
- transplant (mutable history)

> *sigh* Again, I remind you that this whole thing is not Mother's  
> Milk to me.

Yes, I know. I *am* trying to explain things simplified.

> What is "rebase"?

Cuts off the #2 line from X and makes it descend from the #1 head  
instead. Think of two chains of paper-clips, both connected to a  
single common paper-clip (X): rebasing is taking one of those chains  
and hooking it onto the end of the other.

The graph again, after rebasing the first commit in the #2 line onto #1:

         o #2
         |
         |
         o
         |
         |
         o (first in the #2 line, previously descended from X)
         |
         |
         o #1
         |
         |
o #2    o
|       |
|       |
o       o
|       |
|       |
o       o
  \ /   /
   /   /
  / \ /
     o X

The old #2 line is gone, moved (not copied) to descend from #1. **This  
is changing history**, which is why the rebase extension is disabled  
by default.

> At this point we've established that I somehow messed up my repo (at  
> least w.r.t. the repo on my web server).

No, you haven't. You haven't done anything wrong that I can see; you  
just haven't merged yet.