Re: Unreleased fixes in master

[Tait <gnu...@t4...>]

>>> I can ask git about the difference in branches (git log
>>> 5.2.6..master), but they're very diverged, and that command isn't
>>> entirely helpful.
>>
>> Tracking changes via commit messages is one of the things I like least
>> about git.
> 
> The reason that 'git log master..5.2.6' wasn't entirely useful is that
> there was way too much noise. And THAT happened because there were many
> commits that appear in both master and 5.2.6, but that the above command
> isn't recognizing as being on both:

I almost suggested "git log master..5.2.6" but looking at the
repository, Dima is exactly right. It's a little easier to parse
for me in gitk if you enable the "strictly sort by date" option
under View -> edit view. In this view, it's clear that commits
like 1a25a2 / d34da7 are the same. But they're not the same to
git, because they got cherry-picked (rather than merged) from
master over to branch-5-2-stable. In fact, the merge-base
between master and branch-5-2-stable is way back at 07e374 --
the initial split from master!

To keep things simple for now, I'd recommend that commits
destined for a -stable branch be made by checking out that
branch and committing to it. Then merge the -stable branch into
master. This will have the effect of "copying" the commit into
master without the log noise of duplicate commits. Commits
destined for master that will not go to -stable simply get
committed on master and left there.

Now the first time you try to merge -stable into master, it's
going to be ugly because git is having to reconcile everything
from 07e374 up to the tip of each branch. If you're sure that
everything in 5-2-stable is already in master, you can use an
"ours" merge strategy to make the merge a no-op placeholder.
(NB: That's "ours" if you have master checked out and say "git
merge branch-5-2-stable". Don't confuse which way the merge goes
or you'll revert changes you didn't mean to.) Subsequent merges
will look to the most recent merge-base between 5-2-stable and
master, so making a commit on branch-5-2-stable and merging
5-2-stable to master will only bring over that commit, even if
other commits have happened on master in the meantime. I hope
I'm explaining that clearly enough.

That work flow will make the git log commands Dima suggested
work the way they ought -- to show what's changed in one
direction or the other without all the noise of duplicated
commits.

Let me add a couple "git work flow" history highlights for
further background. It all started with
https://nvie.com/posts/a-successful-git-branching-model/, and
this is called "Git Flow". After much discussion,
https://www.endoflineblog.com/gitflow-considered-harmful
happened. That second article has been rewritten, without the
rant, as https://www.endoflineblog.com/oneflow-a-git-branching-model-and-workflow.
And you can read about "GitHub flow" and "GitLab flow" and "Git
Ship" and on if you still haven't found a model that fits quite
right. The tldr is they're all variations on how to choose where
to commit and how to merge.

If you've read at least the git flow link, what I'm recommending
is essentially the "develop" (which is master for gnuplot) and
"release branches" portion of that model. I'm ignoring "feature
branches" and "hotfixes" and their idea of how "master" should
work because that's just extra complication at this stage.

If there's just one take-away from this, it's try to avoid using
cherry-pick.