Re: Unreleased fixes in master

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

> ...
> Back to my original question - why would I ever want to
> merge the stable and development branches?
> That was never the plan.
> ...
> 
> > 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?

The rationale is exactly the present example. Just as one would
rather make, then call a function from two places instead of
copy-and-paste the code in both places, it's preferable to make
a commit only once. The notion is that once created, the stable
branch contains mostly fixes and updates that should apply in
both places (stable and master), so it makes sense to pull those
fixes and updates from stable into master (which a merge does).
It doesn't usually go the other way because fixes on master may
not be relevant to stable because they apply to new features and
other changes that stable doesn't have.

When merging, git looks at the tip of branch A, tip of branch B,
and history back to the common ancestor of A and B (called the
merge-base). It doesn't offer a way to indicate,
commit-by-commit, "merge this and this and not that and then
this..." That makes it difficult to work the way you want, where
all work happens on master and then different bits and pieces
filter back to other places. As you've found, it can be done
with cherry-pick, but then some of the other utilities, like git
log, become less useful. Pragmatically for gnuplot, that means
"git log" can provide the change log for a given branch, but
comparisons across branches have to be done manually, just as
would be the case with a manually-maintained ChangeLog file.

When I started with git, I wanted to do what you're doing. I
learned to accommodate my work flow to git and actually like it,
now. I don't know much about darcs, but I think it would be a
much better fit for how you want to work. (Unfortunately,
SourceForge probably doesn't support it?) Darcs embraces the
concept of creating a patch, and then moving/copying it around.
Critically unlike git, that does not change the patch
identity.

Anticipating the "why is git this way?" question, remember one
of git's design imperatives was to have a single small token be
enough to ensure all of history was intact and unaltered
(including by a possibly malicious actor). Other systems don't
deliver that guarantee, and as a result they can be more free
with their history.

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

Anything but CVS. The biggest issue with CVS is versioning each
file separately, rather than having commits and a uniform state
across the whole repository. There are so many other issues
though, including that since nobody uses CVS anymore, support
for it is hard to come by for a Windows application. TortoiseCVS
is basically not functional anymore on Win10, and while WinCVS
still works if you can find the installer, it's a constant
frustration working around its various quirks and bugs.