[lmi] wxProgressDialog z-order anomaly

[Greg Chicares]

[Much of this introduction has been discussed in recent personal
email, but I'll summarize it for the list.]

These anomalies:
  https://trac.wxwidgets.org/ticket/13185
  https://trac.wxwidgets.org/ticket/13933
slipped into the 2017-11-01 release because we had upgraded to
gcc-6.3.0 (whereas gcc-4.9.x, due to system-header differences,
has actually been using wxGenericProgressDialog all along).
For the time being, I've changed lmi to use the generic version
in all cases. Although it's still early in the month, I've
pushed that as a month-end release candidate so that we stand
ready to release it quickly to anyone who's sorely troubled
by these issues.

Next, I'll work on these changes:
  https://github.com/vadz/lmi/pull/60
which address certain slight GUI anomalies--for example, a
depressed toolbar button might not repaint as quickly as
expected on some machines in certain circumstances. To that
end, I'll first do the following, which I recite here mostly
for my own future reference (a copy-pastable list of commands
that are known to have worked extends my comfort zone)...but
at the last step, things go awry...

# Add Vadim's github repository as a remote, giving it a name
# that doesn't begin with 'v' because so many branch names
# begin with 'v' that autocompletion becomes unworkable.
# ['g' wasn't a good choice either...see far below]
git remote add github-vz https://github.com/vadz/lmi.git

# Grab an up-to-date local copy of all branches on that remote.
# Running this again later updates an existing local copy.
git fetch github-vz

# Locally alias Vadim's no-xslfo branch.
git branch vz-no-xslfo github-vz/direct-pdf-gen-master

# Establish my own no-xslfo branch for code review.
git branch gwc-no-xslfo `git merge-base master vz-no-xslfo`

# Now I think I can push this without harming the savannah
# repository.
git push origin gwc-no-xslfo

# And now (as discussed off-list) I should be able to merge
#   https://github.com/vadz/lmi/pull/60
# easily, without laboriously downloading patches from github,
# and it should be a fast-forward merge if I do it now; AFAICT,
# the command for that is:
git merge --ff-only github-vz/menu-refresh-fix

Except that doesn't work:

/opt/lmi/src/lmi[0]$git merge --ff-only github-vz/menu-refresh-fix
fatal: Not possible to fast-forward, aborting.

Well, this isn't svn, so I can make as many mistkaes as I want and
still expect to clean them up neatly, as long I don't push them;
so, ignoring the advice given here:
  http://lists.nongnu.org/archive/html/lmi/2016-12/msg00016.html
and forging blithely ahead:

/opt/lmi/src/lmi[128]$git merge github-vz/menu-refresh-fix
Merge made by the 'recursive' strategy.
 single_choice_popup_menu.cpp | 32 +++++++++++++++-----------------
 single_choice_popup_menu.hpp | 10 ++--------
 2 files changed, 17 insertions(+), 25 deletions(-)

/opt/lmi/src/lmi[0]$git log --graph --oneline HEAD~2..HEAD
*   ebcf1b2dd Merge remote-tracking branch 'github-vz/menu-refresh-fix'
|\  
| * 188309c53 Repaint area covered by SingleChoicePopupMenu after showing it
| * 4bea744df Don't derive SingleChoicePopupMenu from wxWindow
| * c334ae093 Simplify SingleChoicePopupMenu by using wxWidgets functionality
* ad4e45100 Improve command to test mirror synchronization with server

Is it still a fox-trot merge
  https://developer.atlassian.com/blog/2016/04/stop-foxtrots-now/
if all the asterisks between the first and last lines are in one column?
And shouldn't there be a second-to-last line with just "|/"?
Maybe I need to run git-log from the original point of divergence...

/opt/lmi/src/lmi[0]$git merge-base master github-vz/menu-refresh-fix
188309c53b2a759516024fef525e8f31fa07c6fc
/opt/lmi/src/lmi[0]$git log --graph --oneline 188309c..HEAD
* ebcf1b2dd Merge remote-tracking branch 'github-vz/menu-refresh-fix'
* ad4e45100 Improve command to test mirror synchronization with server
[snip nine lines of purely linear history]
* 8784138ae Improve documentation

I thought that would just expand the scope of the graph, but instead
the commits along the branch got collapsed.

I tried adding '--all' just to see what would happen, but that didn't
show me the recent nonlinear zone in the graph that I expected to see.
Instead, it produced two scary effects: it filled a 'less' buffer
with tons of old history, and it caused a robot to phone me with an
emergency notification that my "microsoft license key" has expired.

But I can alter the fabric of time:

/opt/lmi/src/lmi[0]$git log -2 --pretty=oneline
ebcf1b2dd431164716241205f20068b342af9485 Merge remote-tracking branch 
'github-vz/menu-refresh-fix'
ad4e451000e7982366fb9152d2c3d9b4dca73066 Improve command to test mirror 
synchronization with server

/opt/lmi/src/lmi[0]$git reset --hard ad4e45100

Looking at the advice given when I last did a fox-trot merge:
  http://lists.nongnu.org/archive/html/lmi/2016-12/msg00016.html
I think maybe I want to do this:

/opt/lmi/src/lmi[0]$git pull --rebase github-vz menu-refresh-fix
>From https://github.com/vadz/lmi
 * branch                menu-refresh-fix -> FETCH_HEAD
First, rewinding head to replay your work on top of it...
Applying: Improve documentation
Applying: Implement NAAR solves in an expedient manner
Applying: Designate release candidate 20171012T2109Z
Applying: Refine git configuration in chroot
Applying: Fall back on generic progress dialog to work around regressions
Applying: Dismiss a marked defect [382]
Applying: Designate release candidate 20171101T2204Z
Applying: Synchronize more than one recent commit to local mirror
Applying: Synchronize files most recently git-pulled to local mirror
Applying: Name konsole tabs more klearly
Applying: Improve command to test mirror synchronization with server

As a general rule, maybe that's what's wanted, because the history
seems linear, without any "fox-trot" knot:

/opt/lmi/src/lmi[0]$git log --graph --oneline f79cec2b4^..HEAD
* ea879fef0 Improve command to test mirror synchronization with server
* f492a5de8 Name konsole tabs more klearly
* aff831fa1 Synchronize files most recently git-pulled to local mirror
* 5861eba41 Synchronize more than one recent commit to local mirror
* b244d52db Designate release candidate 20171101T2204Z
* b9a40d891 Dismiss a marked defect [382]
* 17acc2aa2 Fall back on generic progress dialog to work around regressions
* b6d7b659b Refine git configuration in chroot
* c433c728b Designate release candidate 20171012T2109Z
* abbb1db3d Implement NAAR solves in an expedient manner
* ee71c7709 Improve documentation
* 188309c53 Repaint area covered by SingleChoicePopupMenu after showing it
* 4bea744df Don't derive SingleChoicePopupMenu from wxWindow
* c334ae093 Simplify SingleChoicePopupMenu by using wxWidgets functionality
* f79cec2b4 Enable and apply stable and security upgrades in chroot

However, in this case, there's a practical problem. I don't want to
rewind across any "Designate release candidate" commit. I understand
that git mavens might say I should create "release branches", but I
can learn git only at a finite rate, and sometimes I feel like I'm
going too fast, like a participant in a hot-dog-eating contest (USA
cultural allusion--it's like gavage in foie gras production, except
the subjects are human and they stuff themselves willingly). In
this case, origin/master has this commit:
  bd4bcb5 Designate release candidate 20171101T2204Z
and I don't want to alter the history that preceded it, turning it
into some new and different c433c728b. Therefore, do I really want
  git merge github-vz/menu-refresh-fix
(without '--ff-only') in this situation, even if it is a fox-trot?

Pending expert advice, let's
  $git reset --hard ad4e45100
again and practice some simpler git stuff. I want autocompletion
to be tidier than this:

/opt/lmi/src/lmi[0]$git checkout g [press Tab to autocomplete]
git-svn                               github-vz/menu-refresh-fix
github-vz/automake-tests              github-vz/new-boost
[...snip twelve lines...]
github-vz/master-new

and in theory I might rename 'git-svn', but that's presumably
the zeroth commit and it seems unwise to disturb ancient relics,
so let's change the 'github' thing I recently added. Apparently
'git remote rm' should remove it (so that I can later recreate
it with a different name):

/opt/lmi/src/lmi[0]$git remote    
github-vz
origin
/opt/lmi/src/lmi[0]$git branch
  gwc-no-xslfo
* master
  vz-no-xslfo

/opt/lmi/src/lmi[0]$git remote rm github-vz 

/opt/lmi/src/lmi[0]$git remote             
origin
/opt/lmi/src/lmi[0]$git branch             
  gwc-no-xslfo
* master
  vz-no-xslfo

That's surprising:

https://git-scm.com/book/en/v2/Git-Basics-Working-with-Remotes
| git remote rm
| Once you delete the reference to a remote this way, all
| remote-tracking branches and configuration settings
| associated with that remote are also deleted.

Why do I still have a 'vz-no-xslfo' branch? Isn't that a
"remote-tracking branch" that should have been deleted?
It's a branch the corresponds to a remote, but I guess it
doesn't "track" the remote branch in some sense. Yet it's
not "local" either, in the following sense:

/opt/lmi/src/lmi[0]$git branch --merged
  gwc-no-xslfo
* master

Well, no matter--I can use the '--force' if necessary to
vaporize branches:

/opt/lmi/src/lmi[0]$git branch --delete gwc-no-xslfo 
Deleted branch gwc-no-xslfo (was f79cec2b4).
/opt/lmi/src/lmi[0]$git branch --no-merged          
  vz-no-xslfo
/opt/lmi/src/lmi[0]$git branch --delete vz-no-xslfo 
error: The branch 'vz-no-xslfo' is not fully merged.
If you are sure you want to delete it, run 'git branch -D vz-no-xslfo'.
/opt/lmi/src/lmi[1]$git branch --delete --force vz-no-xslfo
Deleted branch vz-no-xslfo (was 0c85a7a99).

No more branches or remotes now?

/opt/lmi/src/lmi[0]$git branch
* master

/opt/lmi/src/lmi[0]$git remote
origin

Well, not actually--I guess I could have answered my own question
about remote "tracking" branches with commands like these:

/opt/lmi/src/lmi[0]$git branch --remotes
  origin/HEAD -> origin/master
  origin/gwc-no-xslfo
  origin/master
/opt/lmi/src/lmi[0]$git branch --all    
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/gwc-no-xslfo
  remotes/origin/master

I certainly don't want to remove any of those except 'gwc-no-xslfo'.
And there's no point in removing that one except to prove that I can,
but I do want to prove that to myself. The inverse of the commands
that created it:

git branch gwc-no-xslfo `git merge-base master vz-no-xslfo`
git push origin gwc-no-xslfo

is apparently either this:

git branch --delete --remotes

or one of these:

git remote prune [--dry-run] origin

which I tried first because it has a '--dry-run' option, and
which apparently does nothing in this situation;

git remote update --prune

(but it seems weird to update and then prune); or

git remote rm gwc-no-xslfo

which sounds like exactly what I want, except...

/opt/lmi/src/lmi[0]$git remote --verbose
origin  address@hidden:/srv/git/lmi.git (fetch)
origin  address@hidden:/srv/git/lmi.git (push)

....I certainly don't want to remove any of those, and thus
'gwc-no-xslfo' is apparently a "remote branch" but not a "remote".

But here's another idea:

git push origin :gwc-no-xslfo

where the colon means "delete":

/opt/lmi/src/lmi[0]$git push origin :gwc-no-xslfo --verbose
Pushing to [my identity, at-sign,] git.sv.gnu.org:/srv/git/lmi.git
[...credentials validated...]
remote: Sending notification emails to: address@hidden
To git.sv.gnu.org:/srv/git/lmi.git
 - [deleted]             gwc-no-xslfo
updating local tracking ref 'refs/remotes/origin/gwc-no-xslfo'

The verbose output seems promising, and this command seems to
confirm that it worked:

/opt/lmi/src/lmi[0]$git branch -a
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/master

I was worried because the 'gwc-no-xslfo' thing persisted here:
  http://git.savannah.nongnu.org/cgit/lmi.git/refs/
for a minute, but probably just as a caching artifact, because
it's gone now.

Okay, so I've figured out several ways to do the wrong thing,
and how to revert experimental mistakes. But how can I integrate
  https://github.com/vadz/lmi/pull/60
without altering history prior to the latest release candidate?