Re: [lmi] wxProgressDialog z-order anomaly

[Vadim Zeitlin]

On Sat, 4 Nov 2017 15:41:59 +0000 Greg Chicares <address@hidden> wrote:

[... many git commands ...]

 I'm not sure if it's useful to review all of these commands (and their
results) in details, because you seem to have mostly figured everything out
correctly already -- except for the root cause of the problem, but then I
don't see it neither and I suspect that somehow the commands given in your
email were not executed exactly as written.

 Let me describe what you have right now instead and describe how I would
investigate the problem instead:

 So, first I would check what do we have now. For this I need to know when
was the PR branch split from master:

        $ git merge-base master github/menu-refresh-fix
        f79cec2b455693b9ccf81ce4a0116e88f7d6bf64

(BTW, just in case: the name of the branch can be seen near the top of the
page, just under the PR title -- you would also see the git commands
specifying how you could merge this branch near the bottom of the page if
you were logged in, but just the branch name should be mostly sufficient).
This commit is nothing special, it was just the latest master commit in my
local master when I did this change (notice that I forgot to update it,
Savannah master did have a couple of more commits even back then).

 It so happens (but this is just a pure coincidence), that this is also the
merge-base of direct-pdf-gen-master branch and master. But, even these 2
branches start from the same master commit, they diverge and contain
completely different changes, i.e. you have this graph, where the
horizontal axis is time and goes in the usual direction and I've also shown
that there were more commits done on master (exactly 11 of them at the time
of this writing) since then:


              *---*---... about 150 more ... ---*---* direct-pdf-gen-master
             /
    --- *---*---*--- ... 8 more ... ---*---* master
             \
              *---*---* menu-refresh-fix

 So it makes total sense that you can't fast-forward a branch based on
direct-pdf-gen-master to menu-refresh-fix, they're not collinear. OTOH if
you did create a new branch starting from the base commit (the one where
the graph above bifurcates), as you wrote:

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

then you should be able to fast-forward it to menu-refresh fix because they
would indeed be on the same line. I.e. the command above directly followed
by

GC> git merge --ff-only github-vz/menu-refresh-fix

really should have worked.

 If it didn't, you must have either done some changes to gwc-no-xslfo
branch or were on a wrong branch. The first can be ascertained by doing

        $ git log --oneline master..

(I use "--oneline" because I'm not interested in commit details, I just
want to see if there were any of them and, if so, which ones) which would
show you all the commits done in the branch since it split from master. For
the fast-forward merge with menu-refresh-fix to succeed, there must be
none.

 And the second can be checked using either "git branch" or "git
symbolic-ref HEAD" which I have always shown in my zsh prompt.


 But the most important thing is that even if the merge above had worked,
this wouldn't really help you at all, because your goal is to integrate my
changes in master, not some other branch. I don't know if you intentionally
wanted to combine them with your integration work on PDF generation or not,
but if you did, then I'd like to strongly argue against this: they're
completely different things and it makes no sense to mix them together. Of
course, please don't take this into account if it was just a mistake.

 So, after saying all this, let me finally answer the question:

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

 First of all, let's forget about direct-pdf-gen-branch and gwc-no-xslfo,
they still exist as they did before, but it doesn't matter as we won't use
them at all.

 Instead, let's start by returning to master:

        $ git checkout master

It is presumably always at the latest origin/master (where "origin" is the
remote corresponding to Savannah repository), but it doesn't hurt to check:

        $ git fetch origin

And if this brings any new changes:

        $ git merge --ff-only origin/master

(BTW, I have "ff = merge --ff-only" in the [alias] section of my
~/.gitconfig because I use this command so often).


 Now let's examine the new commits in the branch we want to integrate:

        $ git log ..github-vz/menu-refresh-fix
        ... shows my 3 commits ...

We can also check, or confirm, that there are some commits in master that
have been done since this PR

        $ git log github-vz/menu-refresh-fix..
        ... shows your commits postdating my PR ...


 This shows that fast-forwarding is impossible and we now have a choice:
either you just merge the branch into master or your replay the changes
done in the branch onto the newest master.

 The first choice is the "native Git" way of doing things. A simple

        $ git merge github-vz/menu-refresh-fix

is enough to do it and while it will indeed create a merge commit, i.e.
result in

                              current
                               master
    --- *---*---*--- ... ---*---*------------* new master
             \                              /
              *------*--------* ------------
                         menu-refresh-fix

there is really no problem with this and, in fact, there is an advantage in
seeing that the 3 commits merged into master as one are parts of
logically-related changes.

 But if you want to preserve the linear history, you have another choice:
replace the 3 commits of the branch on master. This can be done manually by
using "git cherry-pick" to pick the commits one by one:

        $ git cherry-pick github-vz/menu-refresh-fix~2
        $ git cherry-pick github-vz/menu-refresh-fix~1
        $ git cherry-pick github-vz/menu-refresh-fix

Or it can be done by cherry-picking them all at once:

        $ git cherry-pick ..github-vz/menu-refresh-fix

(you can check using "git log" that this commit selection expression
results in exactly the same commits).

 Or, and this is probably the most confusing, but also the most powerful
and, in practice, most useful, way by doing "git rebase": this is a command
which basically automates calling cherry-pick in a loop and also provides
many other handy features via its "-i" (interactive) option, like the
ability to amend commits on the fly, change their order, commit message,
selectively drop some of them and more. In this case you want to rebase the
menu-refresh-fix branch, so you need to switch to it first and, as you
can't switch to a remote branch, you need to create your local branch
first:

        $ git branch gwc-menu-refresh-fix github-vz/menu-refresh-fix
        $ git checkout gwc-menu-refresh-fix

(as you probably already know, you can also combine these 2 commands by
using "git checkout -b", but I give their full form for clarity).

 Now you can rebase, i.e. replay, all the branch commits on master. If you
don't need to do anything fancy, you don't need to use the -i option, so
it's just

        $ git rebase master

It looks like nothing happened as you still have the same (or almost, their
SHA-1s have changed) commits on your branch. Except that instead of

    --- *---*---*--- ... 8 more ... ---*---M master
             \
              A---B---C gwc-menu-refresh-fix

things now looks like this:

    --- *---*---*--- ... 8 more ... ---*---M---A'---B'---C' gwc-menu-refresh-fix

(notice that master is still unchanged and continues to point to "M").

 And this is important because it means that _now_ you can fast-forward
master to this branch, so let's do just this:

        $ git checkout master
        $ git merge --ff-only gwc-menu-refresh-fix

Once this is done, you don't need the branch any longer and you can just

        $ git branch -d gwc-menu-refresh-fix

 And, of course, you end up by doing

        $ git push origin master

to really push out the changes, maybe after doing more commits to improve
or extend my changes.

 I hope this answers your question and this post is already sufficiently
long for me to not go into further details but please let me know if you
still have any specific questions that you'd like me to answer.

 Also note that if you want to change something in my commits before
applying them, there is a simple way to do it with "git rebase -i": please
let me know if/when you'd like to know more about it.

 Good luck!
VZ