How to "push" manually?

[Dennis Brakhane]

On Mon, Apr 6, 2009 at 4:55 AM,  <skip at pobox.com> wrote:
> Folks,
>
> This has been an extraordinarily frustrating exercise for me.  Thank you for
> all the help (and patience).

To avoid further frustration, I'd suggest that you forget (for now)
all the stuff about
rebasing and patch queues (mq). These things are advanced concepts and only
implemented as extensions for a reason: they *extend* mercurial to
suit more workflows.
Think of them as: "if you don't understand what they do or don't know
if you need them,
you don't need them." Get started with core mercurial first (and use
"hg serve" to watch
your repository in a browser, as already suggested) and if you feel
your preferred workflow
can't be done with core mercurial, look into the extensions.

Distributed version control might be confusing at first, but if you
start with the even more confusing
heavy stuff, you will simply be overwhelmed.

To summarize, your problems occured because you pulled a foreign
bundle in your local 'master'
repository even though you weren't sure you want those changes. Most of this has
already been suggested, but I think the following should help you
learning mercurial:

1. Read the hgbook, it's nicely written (keep in mind that it was
written at a time before hg 1.0, so
some things might be outdated, AFAIK, the book is being updated, but I
do not know the status)

2. Create (at least) two clones of your server repository:
One is for "outgoing" changes only, that is, you only push changes
that you want on the server
on this one. You only push from this repository to the server. This
way, it's easier to keep track
of what's in the server. Everytime you want to start on a new
feature/bugfix or just try something out, you
clone from the "outgoing" changeset and do whatever you wanted to do.
If your satisfied with the result, push it
to outgoing, if not, discard the clone. In case you work on two clones
in parallel, and you want to keep both clones,
pull from one of your working clones into the other working clones.
Then merge there and if your happy, push it
to the outgoing clone (and from there to the master)

3. Don't accept bundles, only accept patches (hg export), they can be
"hg import"ed like
bundles, but you can see beforehand if you really want them. Even
then, first create a clone from the
"outgoing" repository, import the patches into this clone (you might
have to merge now if the
patch was done for a revision that is no longer the tip) and review.
If you're happy, push them, if not, simply
delete the clone.

4. As stated above, don't bother with mq, pbranch, rebase or all the
other history altering extensions for now. They
will still be there when you know you need them (and if you *know* you
need them, you will also know how to use them)

And most important:
5. DON'T PANIC! :-)