Re: Unreleased fixes in master

[sfeam <me...@uw...>]

On Friday, 22 February 2019 09:36:40 Tait wrote:
> >>> 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!

That was the intent.
Sorry if my brain is on a different planet from the git designers,
but I don't see why I would ever want to merge the stable
and development branches.  The entire _point_ of having a development
branch is to try things out and only carry back only a few of the 
successful changes into the stable branch.


> 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. 

No. That is backwards from the gnuplot development model.
Nothing ever goes into stable first and then 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.

Sorry, my mind just doesn't work that way.
I have had no luck with "merge".
"git cherry-pick" is the only mechanism that works for me.
 
> 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.

Back to my original question - why would I ever want to
merge the stable and development branches?
That was never the plan.

> 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.

In my world-view of the process there is no such "direction".
The changes go neither from A->B or B->A.  Instead A and B
progress in parallel, sharing a common core that was the point
of the branching.
 
> 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". 

I have just read that.
I don't like it at all.

> After much discussion,
> https://www.endoflineblog.com/gitflow-considered-harmful
> happened. 

That one is much closer to my way of thinking.
Except that I do not see any reason to merge a release branch
back into master (or development or whatever you want to call it).
What would be gained by merging?  
That is a serious question - what is the rationale for even wanting
to do a merge?

> 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.

All I can say at this point is that "git cherry-pick" is the thing
that made git usable for me.  If I can't use that then I think
I'd rather go back to CVS.

	call me a luddite, or an old-fogie, or whatever you choose

		Ethan