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

[Steve Fink]

On 05/07/2017 01:44 AM, Uwe Brauer wrote:
>>>> "Rainer" == Rainer Woitok <rainer.woitok at gmail.com> writes:
>     > Uwe,
>     > On Friday, 2017-05-05 10:10:18 +0000, you wrote:
>
>     >> ...
>     >> Mercurial queues is  on my Todo list for sure.
>
> [Snip]...
>
>
>     >        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.
>
> Thanks very much for the detailed answer. Since this is entirely new to
> me it will require some study and practice from my side. If I run into
> difficulties I might come back with questions.

The usual mq caveats should be noted. Most of them are pretty well 
spelled out in the intro you pointed to on 
https://www.mercurial-scm.org/wiki/MqExtension but more generally, core 
hg developers aren't really interested in supporting the mq workflow and 
so new stuff doesn't always mesh that well with it.

For example, an mq that did not destroy information, but instead used 
obsolescence markers, would be interesting and potentially a nice UI, 
but as far as I know no one's done it. And one of the big advantages of 
mq is the simplicity/understandability of the patch files, but they 
duplicate information in the dag. Which means it's easy for them to get 
out of sync. And mq just punts on some of the hard problems, which 
results in some unnecessary manual merge/rebase work.

I used to be a heavy mq user. I wrote my own extension to automatically 
commit any changes made to the patch directory, to avoid the history 
loss (in case I needed to roll back to something earlier). Now, I use 
evolve and a small handful of aliases and things to mostly reproduce my 
old mq workflow. I'm more comfortable with my current setup, and I feel 
like when I run into issues, I just have to keep in mind the core hg dag 
concepts rather than going through an extra layer and figuring out what 
mq is doing to the underlying repo. (There are still things that mq 
makes easier, but it also makes some things harder, and if I'm making a 
tradeoff between the two I prefer to choose the option that more closely 
follows the underlying data structure. My learnings are more generally 
applicable that way.)