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

[Vadim Zeitlin]

On Thu, 16 Jul 2020 00:18:45 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

GC> OTOH, if I hold back all new commits until after I've merged the
GC> entire wxGrid branch, doesn't that preserve the linearity of git
GC> history, which would be lost if I commit anything before merging?

 Yes, this is true. But for Git linearity is not a goal. In fact, for some
people it's even an anti-goal and Git project itself (which, surprisingly,
uses Git for its own sources) doesn't have almost any non-merge commits in
master, i.e. there is no linear part of it at all.

GC> (You may regard that as inconsequential, but I still imagine lmi's
GC> history to be one-dimensional, and that linearity is comforting
GC> to me. That's my lifeline; I don't want to tie knots in it.)

 It may well be so, but having linear history doesn't really have any
advantages and in a project with more than one developer has very real
disadvantages. We mostly avoid those because we almost never modify the
same areas in parallel and so it's always easily possible for me to rebase
my changes before submitting them, but even in our case this linearity is
just an illusion, because the actual development branch hadn't split off
from master at where it currently (after my rebase) seems to do it, and
even though it doesn't really matter, it still seems wrong (to me, anyhow)
to record history as we wish it occurred for aesthetic purposes, rather
than like it actually did.

 Also, non-linear history, with the real merge commits does have its
advantages: for example, you could easily skip all 44 commits in my PR by
not looking at them when using any (semi-)graphical Git log viewer,
including "git log --oneline --graph", because they're neatly packed in a
separate branch. While linearizing them means that you can't easily
separate them from the other, unrelated changes.

 Merges are really _nice_. They have horrible reputation because of the
traumatic experience that many people had with them with CVS or SVN, but
they're not at all the same thing in Git.


GC> Right now, in a throwaway chroot (I'm starting to use these like
GC> VMs), I have:
GC> 
GC>   git log --graph --oneline --all
[... log of "tt" branch ...]
GC> in a palette of colors so vivid that I want to put on sunglasses,
GC> and I have some notion of what that is, but it boggles my mind...
GC> so I drop '--all', and (almost) everything becomes simple again.

 This is not a good example of a good use of merges because "tt" is a
long-lived branch which, itself, has never been merged in master (for some
good, and maybe some not so good, reasons) and so its history is just a
sequence of merges from master into it. With normal master development,
you'd typically have just a few colour lines running in parallel (each
colour is a branch) and seeing the different branches is helpful rather
than confusing.

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

 Yes, it would be linear. Of course, if you really care about linearity and
only linearity, you could also make any commits you want right now and then
later just rebase the branch before fast-forwarding to it. And, for this
branch, it doesn't really matter if it gets rebased again, because it has
already been rebased a few times and its actual history is already lost in
the mists of time.

 But I still believe that seeing merge commits in the history gives a
better idea of what happened and allows to navigate history more easily and
I'd love to convince you one day that it's worth losing the illusion of
linearity for it. I'm realistic enough to understand that it's not going to
happen right away, however...

 Best regards,
VZ

pgpOCs3pODIvP.pgp
Description: PGP signature