hg-git: push -d default seems not to work.

[Dr Rainer Woitok]

Uwe,

On Friday, 2017-05-05 10:10:18 +0000, you wrote:

> ...
> Mercurial queues is  on my Todo list for sure.

Using Mercurial Queues probably requires  a work flow slightly different
from what the typical Git user is accustomed to.  Using Mercurial Queues
you are working with TWO repositories, the main repository you cloned or
pulled from upstream and a "patches/" sub-repository (which, however, is
different from normal  Mercurial sub-repositories  in that it resides in
".hg/").  You can think of this sub-repository as a personal sketch-pad,
and nobody other than you ever needs to see it.

Whenever you feel like it, you can use

   hg qrefresh
   hg commit --mq

to commit in the "patches/" sub-repository the current state of patching
your bug.   These commands will save the current changes to the main re-
pository in a "diff" file  stored in the  "patches/"  sub-repository and
will also create or update the single new changeset in the main reposit-
ory which is  associated with  your patch.   This single  new changeset,
however, is not permanent -- whenever you want, you can "hg qpop" it off
your main repository thus making the main repository pristine again, and
whenever you want, you can "hg qpush" the patch back on top of the curr-
ently checked out changeset.

Should patch development reach a dead end,  you can "hg qpop" your patch
off the main repository, check out the last reasonable changeset in your
"patches/" sub-directory,  reapply this old  version of the patch to the
main repository and continue from there.  The next commit in the "patch-
es/" sub-repository will then create a new head,  but since this "patch-
es/" sub-repository  is only your sketch-pad,  the ugliness of its graph
simply doesn't much matter.

If you are really goofing  (like omitting a trailing semicolon in a line
of Perl code), you just correct this in the main repository and then run

   hg qrefresh
   hg commit --mq -m 'Not my day :-('

Nobody will ever notice.

Finally,  you'll have a single changeset  containing a cute little patch
at the tip of your otherwise pristine main repository  and all tests ran
flawlessly.  Thus you somehow have to finish the patch off.

  * If you are rather sure nobody else  meanwhile messed with files cov-
    ered by your patch, you can just run

       hg qpop                                          # Pop patch off.
       hg pull                       # Get recent changes from upstream.
       hg qpush                              # Reapply patch to new tip.
       hg qrefresh -m 'Nice patch description.' -u '<Me at Home>'
       hg qfinish -a        # Permanently move patch to main repository.
       hg push                                    # Push patch upstream.
       hg commit --mq -m 'Delete patch just pushed upstream.'

  * Otherwise you should use the save way:

       hg qpush
       hg qrefresh -m 'Nice patch description.' -u '<Me at Home>'
       hg qfinish -a
       hg pull                       # This might now create a new head.
       hg merge                                          # If necessary.
       hg push                                    # Push patch upstream.
       hg commit --mq -m 'Delete patch just pushed upstream.'

So when working with Mercurial Queues  there normally is no need to cre-
ate new named branches in your main repository,  not even new heads, ex-
cept when "hg pull"  does create new changesets.   Thus the graph you're
interested in remains pretty linear with regard to your patch.

Sincerely,
  Rainer