Re: [lmi] Latent lmi anomaly unmasked by new wx

[Greg Chicares]

On 2020-07-15 14:48, Vadim Zeitlin wrote:
> On Wed, 15 Jul 2020 14:19:35 +0000 Greg Chicares <gchicares@sbcglobal.net> 
> wrote:

[...some isolated anomaly that's trivial to fix...]

> GC> I'm not going to fix it immediately, because introducing a new
> GC> commit now changes the base commit
> 
>  This is not going to create any problems for the future merge, so I'm not
> going to rebase anything as you would still be able to merge the current PR
> without any problems.
> 
>  If you'd like to understand why is this so, instead of just taking my word
> for it, let me try to explain why: I've only rebased the PR yesterday
> because the commit updating wxWidgets and wxPdfDoc versions doesn't really
> belong to this PR, it only was included in them because later commits
> simply wouldn't compile without it (because they use new wxWidgets API
> which didn't exist in the wxWidgets version previously used by lmi). So,
> after you've cherry-picked this commit in master, I could rebase the PR on
> the latest master to exclude it commit and leave only the "real" changes in
> it.

Okay, I think I understand so far.

> But this logic doesn't apply for any future changes, i.e. if you make
> some changes to skin.xrc right now, there is no need to rebase the PRs
> again. It could be done, but nothing would be really gained from it.
> 
>  When you merge the PR branch later, it will just result in the picture I
> drew yesterday, with a merge commit with 2 parents: the latest lmi master
> (whatever it is by then) and the latest commit from the PR. And this is
> perfectly fine and doesn't create any problems at all, as long as there are
> no conflicts, i.e. as long as there are no changes in master to the same
> lines that were also changed by the PR (i.e. basically census_view.?pp
> files).

OTOH, if I hold back all new commits until after I've merged the
entire wxGrid branch, doesn't that preserve the linearity of git
history, which would be lost if I commit anything before merging?
(You may regard that as inconsequential, but I still imagine lmi's
history to be one-dimensional, and that linearity is comforting
to me. That's my lifeline; I don't want to tie knots in it.)

Right now, in a throwaway chroot (I'm starting to use these like
VMs), I have:

  git log --graph --oneline --all

* 2922db91a (HEAD -> master, xanadu/census-view-grid) Disallow single cell 
operations when non-current row is selected
* b3ac65ba8 Allow wxGrid to compute census view column sizes more efficiently
* d4ad57bc1 Disallow "Edit/Run" cell when multiple grid rows are selected
...
* 3e9f8af66 Add census_view variant with wxGrid
* 193e804a3 Refactor census view to enable several implementations
* 697767083 (xanadu/master, origin/master, origin/HEAD) Upgrade wxWidgets and 
wxPdfDoc
* ce7f5faca Abjure the /dev/clipboard cygwinism

and it's perfectly linear far into the past. Farther back, I see:

* \ \ \ \ \ \   40a01d597 Merge branch 'master' into tt
| |\ \ \ \ \ \ \  
| * \ \ \ \ \ \ \   c3cbe0ed8 Merge branch 'master' into tt
| |\ \ \ \ \ \ \ \  
| * \ \ \ \ \ \ \ \   0782addaf Merge branch 'master' into tt
| |\ \ \ \ \ \ \ \ \  
| * \ \ \ \ \ \ \ \ \   a1a443b97 Merge branch 'master' into tt

in a palette of colors so vivid that I want to put on sunglasses,
and I have some notion of what that is, but it boggles my mind...
so I drop '--all', and (almost) everything becomes simple again.

If I save pending changes off to the side until after I've
merged this branch, then I'll have a more linear history, right?

I'm still interested to know whether that's correct, but it's
kind of academic now, because now that I've used the new census
manager, I'm unwilling to go back to the old one, so I'm eager
to get this merge done as soon as I can (which won't be until
the weekend because I have some other requirements that'll take
all my time for the next couple of days).