Re: [lmi] wxProgressDialog z-order anomaly

[Vadim Zeitlin]

On Sun, 5 Nov 2017 17:49:49 +0000 Greg Chicares <address@hidden> wrote:

[...]

 To avoid making this email even longer than necessary, I'm trimming all
parts of your email that don't contain any questions and that I don't have
any comments about. I hope you don't mind this, but please let me know if I
missed any (perhaps implicit, because I do think I got all the explicit
ones) questions to be answered.

GC> BTW, is there some place in git-scm.com/docs/ where the syntax of
GC> <path> arguments is explained?

 Yes: the reference documentation is at

        https://git-scm.com/docs/gitrevisions

(also accessible as "man gitrevisions" locally) and a more tutorial-like
introduction can be found in e.g.

        https://git-scm.com/book/en/v2/Git-Tools-Revision-Selection

GC> I don't remember ever seeing a leading or trailing '..', for example. I
GC> guess that there's an "empty" argument there that defaults to the
GC> current branch name (and adding 'master' in the commands above, then
GC> rerunning them, seems to confirm that).

 Yes, the omitted argument is taken to be HEAD (and in your case HEAD is
master).

[...]
GC> The final reason why this troubles me is: isn't this a fox-trot merge?
GC> If not, why not? Or if so, then why is this one okay when others aren't?

 It is not what is called a fox-trot merge (which is not an official term,
BTW, and I'm not sure if I really like it as it seems not very clear to me
but, admittedly, I'm not the best person to ask about dance-related terms).
To answer the "why not" question, a fox-trot merge is, by definition, a
merge which has origin/master as its second parent, i.e. it's a merge of
origin/master into some other branch (which may, and usually is, the local
master). This one merges a topic branch into master, which always is, and
remains, collinear with origin/master, so it's a perfectly normal and good
merge.

 To make it even more explicit: a fox-trot merge would happen if you had
done this merge (or any other local changes), while in the meanwhile I
would have committed something to origin/master and then, usually by just
doing "git pull" you would have merged origin/master again into your
master, before pushing it out.

 Git itself doesn't care about fox-trot merges, but they make history more
confusing as in the example just above there is no good reason why
origin/master should have been merged into, basically, itself. The end
result would still be the same but it would be more clear if this fox-trot
merge didn't exist.

[...]
GC> (I think there's a way to tell git to use a specified alternative tool,
GC> but that's not what I'm trying to learn today.)

 Yes, see e.g. "git difftool --help". As you might have heard before, I
recommend just using Vim-fugititve.

[...]
GC> In a way, it's as though you had rebased your changeset on today's
GC> master HEAD, and I had then applied it as a fast-forward merge.

 Exactly.

GC> And only after writing that do I understand this:
GC> 
GC> >  Or, and this is probably the most confusing, but also the most powerful
GC> > and, in practice, most useful, way by doing "git rebase"
[...]
GC> ....which seems to say exactly the same thing, right?

 Yes. Again, "git rebase" can do [much] more, but at the most basic level
it just automates cherry-picking many commits in a row and its extra
features just add other things to do before or after cherry-picking.

GC> >  Also note that if you want to change something in my commits before
GC> > applying them, there is a simple way to do it with "git rebase -i": please
GC> > let me know if/when you'd like to know more about it.
GC> 
GC> As a general rule, I imagine that it's an excellent idea to adopt
GC> your changes as given and only then modify them (if desired) in a
GC> separate, subsequent step. That way, you can see whether or not
GC> I've applied all of your changes faithfully; and, if an error is
GC> introduced, we can determine who introduced it. This seems far
GC> better than a modify-while-adopting approach whereby I commit
GC> altered versions of your changes, with the woeful effect that
GC> the point where a defect was introduced cannot be ascertained.

 From my point of view, the preferred order for integrating my changes is:

1. Merge my changes (maybe after doing more commits in the branch,
   fixing/adding things, of course).

2. Cherry-pick (as you did) or rebase my branch to ff-merge it (again,
   maybe with extra changes in separate commits).

.
.
.

99. Apply slightly different but not identical changes as different
    commits.

 (1) is ideal because I can just delete my branch after the merge: this
will only work if the merge really did happen and I can be sure that no
commits were left/forgotten. A nice extra benefit of (1) is that GitHub
will automatically close the PR opened for the branch as it detects that
the branch was merged.

 (2) is not really much more trouble because I can just rebase my branch
on the latest master and Git will skip all already applied commits _if_
they are identical: it's smart enough to know that commits with different
metadata can still have identical body (so you can change timestamps,
commit parents and even commit messages if you want to reword them, this is
not a problem as long as the commit body is exactly the same), so rebasing
will happen quickly and confirm, again, that no unapplied changes remain.

 (99) is the worst because it can't be handled in any automatic way. If I
want to check whether all changes were applied, I still need to rebase, but
this will now result in conflicts for each modified commit, and each such
conflict will need to be painstakingly resolved. With many commits (e.g.
~150 in the direct-pdf-gen branch) this becomes prohibitively
time-consuming and so it's easier to just delete the branch and just trust
you to have merged it without forgetting anything -- which is, of course,
not a problem on its own, but I'd still rather have Git safety-net.


GC> Thanks for an informative discussion. In this case, I'll use
GC> the cherry-pick method and push the z-order changes presently.

 FWIW everything seems to have worked just fine and I've just rebased my
branch on master and confirmed that there are no changes remaining and
closed the PR (as well as a couple of other ones that I forgot to close
when they were taken care of, leaving only a single still relevant one at
https://github.com/vadz/lmi/pull/56).


 Thanks for merging this!
VZ