How to "push" manually?
Giorgos Keramidas
keramida at ceid.upatras.gr
Sun Apr 5 21:49:20 CDT 2009
On Sun, 5 Apr 2009 20:56:11 -0500, skip at pobox.com wrote:
> >> 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.
>
> I beg to differ. By incorporating Ben's changes into my repo (not
> realizing what I was doing) I incorporated code I hadn't seen. I
> wanted to "import" it simply so I could work with it. I didn't expect
> to use his code as he wrote it, but this .hg file was an opaque thing
> I couldn't deal with directly. I believe now that I should have
> probably imported his .hg file into an entirely new repository.
Pulling changesets in a repository clone is essentially *always*
bringing in changes that you haven't reviewed yet. They may be changes
that sit on top of a 'past changeset, i.e. if your current version of
the repository history looks like this:
67e2 o [tip] A change you made this morning
| for some stuff that you needed
| to push to the webserver.
|
|
cf34 o
|
|
:
Graph 1. The repository history before pulling.
You can pull changes that Ben made to his own private clone, which was
based on changeset cf34 and end up with a history graph in your local
clone that looks like this:
1937 o [tip]
|
| 67e2 o A change you made this morning
| | for some stuff that you needed
72f4 o | to push to the webserver.
| |
`--------------.|
cf34 o
|
|
:
Graph 2. The repository history _after_ pulling.
At this point you have to `heads' because Ben and you have been working
on two slightly different versions. You can `merge' the two heads, but
you cannot *remove* the changes Ben made.
So if you want to experiment with the changes Ben has made, it is a good
idea to create a `test clone' and only pull Ben's work into the test
clone, until you are satisfied that you have a good understanding of the
way a changeset graph works in Mercurial.
Pulling into a `test clone' should be as easy as:
hg clone my-local-work test-clone
cd test-clone
hg pull http://ben.laptop/his-public-clone
This way you will still end up with two heads like graph 2 above, and
you can look at the changes of Ben in various ways, i.e.:
# Look at the first change Ben made.
hg export 72f4 | more
# Look at the second change Ben made.
hg export 1937 | more
# Look at all the changes Ben made in one patch.
hg diff -r cf34:1937 | more
# Look at the changes from your own local version to Ben's
# latest version of the same code.
hg diff -r 67e2:1937 | more
You can run "hg update [--clean] REV" to any revision of yours or Ben's.
You can even merge in `test-clone' with Ben's work and then pull the
work back into your `local-work' repository, i.e.:
cd test-clone
hg update --clean 67e2
hg merge 1937
hg commit -m 'Merge with Ben'
But if all this turns out to be a bad clone, and you decide that don't
like any of Ben's changes, you can just throw away the `test-clone' and
you are done.
For what it's worth, all this and a lot more is described at the Wiki,
so it may be useful to take a bit of time and read the following
introductory material:
http://www.selenic.com/mercurial/wiki/index.cgi/UnderstandingMercurial
http://www.selenic.com/mercurial/wiki/index.cgi/Tutorial
http://www.selenic.com/mercurial/wiki/index.cgi/QuickStart
A bit more time is needed for the `Hg book' or Bryan O'Sullivan, but it
is an amazing book, absolutely recommended reading, and available online
at:
http://hgbook.red-bean.com/read/
HTH,
Giorgos
More information about the Mercurial
mailing list