gnuplot-beta

Unreleased fixes in master

[Dima K. <gn...@di...>]

Hi.

I'm using the 5.2.6 release, and I just hit a gnuplot bug that we
already fixed back in 2017/11:

  https://sourceforge.net/p/gnuplot/mailman/gnuplot-beta/thread/2603217.PItpvUgmjs%40stonelion/#msg36096047

It looks like this fix is in place in the master branch, but not in the
latest release. Is this intentional? Can we release it?

Thanks!

Re: Unreleased fixes in master

[Ethan A M. <sf...@us...>]

On Tuesday, February 19, 2019 10:50:46 AM PST Dima Kogan wrote:
> Hi.
> 
> I'm using the 5.2.6 release, and I just hit a gnuplot bug that we
> already fixed back in 2017/11:
> 
>   https://sourceforge.net/p/gnuplot/mailman/gnuplot-beta/thread/2603217.PItpvUgmjs%40stonelion/#msg36096047
> 
> It looks like this fix is in place in the master branch, but not in the
> latest release. Is this intentional? Can we release it?

That's a tough call.  I see somewhere on the order of 20-30 commits over
a period of 8 months that are related to that change, touching core files
as well as individual terminal drivers.  That is far more extensive than
I ever used to consider for back-porting from the development version to
the stable source.

I realize that now we are using git, for better or worse.   That probably
makes it more feasible than previously to back-port a large set of changes,
if only because it is easier to back them out again if things break.

But is it a reasonable use of effort?  At some point I think you just have
to say "yeah, there are lot of nice new features and improvements in the
development version that won't appear in an official release until the next
major version (5.4)". 

Anyhow, I guess the answer is "maybe".

			Ethan

Re: Unreleased fixes in master

[Dima K. <gn...@di...>]

Ethan A Merritt <sf...@us...> writes:

> That's a tough call.  I see somewhere on the order of 20-30 commits over
> a period of 8 months that are related to that change, touching core files
> as well as individual terminal drivers.  That is far more extensive than
> I ever used to consider for back-porting from the development version to
> the stable source.

Hmmm. I guess this was done long-enough ago that I assumed the latest
release would include it, especially since it fixes a real problem. By
the way, how are you keeping track of what's in the release and what
isn't? 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.

Thanks
dima

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.

AW: Unreleased fixes in master

[Bastian M. <bma...@we...>]

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

cherry-pick is what I used. The reason behind this is probably that
it resembles what we had been doing with the previous versioning
system CVS.  That is OK for developers closely following gnuplot
development but might be difficult for others indeed.

Let me note that for the past decade (or longer) on the order of 3 out
of 4 commits were done by Ethan. So it's really him who has to be
comfortable with the process.  A more "modern style" way of
handling merges etc. might still make it easier in particular for new
contributors.

  Bastian

Re: Unreleased fixes in master

[Ethan A M. <sf...@us...>]

On Thursday, February 21, 2019 9:52:17 AM PST Dima Kogan wrote:
> Ethan A Merritt <sf...@us...> writes:
> 
> > That's a tough call.  I see somewhere on the order of 20-30 commits over
> > a period of 8 months that are related to that change, touching core files
> > as well as individual terminal drivers.  That is far more extensive than
> > I ever used to consider for back-porting from the development version to
> > the stable source.
> 
> Hmmm. I guess this was done long-enough ago that I assumed the latest
> release would include it, especially since it fixes a real problem.

That's not the development model we have been using.

Trivial bug-fixes are applied for both the stable and development branches
immediately as they are found.  

Non-trivial changes, even bug fixes, are applied only to the development branch.
Often people using the development branch then report related issues
that require additional fixes or re-thinking of the original fix.
After sufficient testing in the development version the original fix and any
follow-ups developed during testing may or may not be back-ported to the
stable branch.  This particular change was non-trivial to begin with and
engendered many follow-up fixes.


> By the way, how are you keeping track of what's in the release and what isn't? 

Changes to the stable branch are tracked in ChangeLog and in NEWS.
I use the bullet-point summary in NEWS to prepare release notes.

In the development branch, the top section of NEWS is a bullet-point list of
what went into 5.3 but not 5.2.

I haven't been updating ChangeLog for the development branch because
people told me that the "git way" was to use commit messages instead.
I have been doing that, but see below.


> 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.  I am seriously considering to switch back to a model where
changes are fully described in a separate ChangeLog and all git commits
simply say "see ChangeLog".  That would require some automated way to
insert the appropriate git hash indices into the text of the ChangeLog.
I have tried a couple of git add-ons that looked like they might help, 
but so far with no success.

The thing is, you can't go back to edit old commit messages like you can
edit a ChangeLog.  That means you cannot fix typos, cannot clarify or
expand bad descriptions, cannot update or redact Email addresses,
cannot forward-link to eventual reversion or to subsequent related patches etc.

My #1 suggestion for improving git would be to move all the commit messages
to a parallel data structure so that they can be edited without invalidating
the orginal commit hash. 

	Ethan

Re: Unreleased fixes in master

[Allin C. <cot...@wf...>]

On Thu, 21 Feb 2019, Ethan A Merritt via gnuplot-beta wrote:

> Non-trivial changes, even bug fixes, are applied only to the 
> development branch. Often people using the development branch then 
> report related issues that require additional fixes or re-thinking 
> of the original fix. After sufficient testing in the development 
> version the original fix and any follow-ups developed during 
> testing may or may not be back-ported to the stable branch.

Sounds like a sane policy to me.

The project I'm most involved with has a more "aggressive" 
development policy. The upside is that genuine fixes get out to 
users more quickly. The downside is that "fixes" with nasty 
unintended side effects also get out, in some cases requiring 
"emergency" releases and engendering regrets.

Given how widely gnuplot is used, I'm with Ethan on this.

Allin Cottrell

Re: Unreleased fixes in master

[Dima K. <gn...@di...>]

Ethan A Merritt <sf...@us...> writes:

> That's not the development model we have been using.
>
> Trivial bug-fixes are applied for both the stable and development branches
> immediately as they are found.
>
> Non-trivial changes, even bug fixes, are applied only to the
> development branch. Often people using the development branch then
> report related issues that require additional fixes or re-thinking of
> the original fix. After sufficient testing in the development version
> the original fix and any follow-ups developed during testing may or
> may not be back-ported to the stable branch. This particular change
> was non-trivial to begin with and engendered many follow-up fixes.

OK. Is your thinking to include this in a 5.4 release at some point in
the future?


>> 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. I am seriously considering to switch back to a model where
> changes are fully described in a separate ChangeLog and all git
> commits simply say "see ChangeLog". That would require some automated
> way to insert the appropriate git hash indices into the text of the
> ChangeLog. I have tried a couple of git add-ons that looked like they
> might help, but so far with no success.

OK. I use git heavily, but never to do anything with lots of branching,
so I wasn't sure what you're doing. Things like "git master..feature"
(i.e. tell me what's on the feature branch that isn't on the master
branch) is exactly the thing that git is supposed to do well, so I
suspect we're doing something incorrectly here.

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:

  dima@scrawny:~/projects/gnuplot$ comm -12 <(git log master..5.2.6 --oneline | cut -d' ' -f 2- | sed 's/ /_/g' | sort) <(git log 5.2.6..master --oneline | cut -d' ' -f 2- | sed 's/ /_/g' | sort) | wc -l
  224

  dima@scrawny:~/projects/gnuplot$ comm -23 <(git log master..5.2.6 --oneline | cut -d' ' -f 2- | sed 's/ /_/g' | sort) <(git log 5.2.6..master --oneline | cut -d' ' -f 2- | sed 's/ /_/g' | sort) | wc -l
  156

  dima@scrawny:~/projects/gnuplot$ comm -13 <(git log master..5.2.6 --oneline | cut -d' ' -f 2- | sed 's/ /_/g' | sort) <(git log 5.2.6..master --oneline | cut -d' ' -f 2- | sed 's/ /_/g' | sort) | wc -l
  635

i.e. there were 224 commits that appear in both master..5.2.6 AND in
5.2.6..master. Taking a random one. Look at this:

  gitk 1f7160945 fb107d74e

These are clearly the same commit, so ideally it should appear on
neither "git log master..5.2.6" nor "git log 5.2.6..master", but it
appears on both. Those commits aren't in a merge, and their immediate
parents aren't the same. How did we get here? Did we cherry-pick it?
Maybe that confuses "git log" a bit?


> The thing is, you can't go back to edit old commit messages like you
> can edit a ChangeLog. That means you cannot fix typos, cannot clarify
> or expand bad descriptions, cannot update or redact Email addresses,
> cannot forward-link to eventual reversion or to subsequent related
> patches etc.
>
> My #1 suggestion for improving git would be to move all the commit
> messages to a parallel data structure so that they can be edited
> without invalidating the orginal commit hash.

Are you really proposing to have a hand-curated NEWS file AND a
hand-curated ChangeLog AND version control?

Re: Unreleased fixes in master

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

On Thursday, 21 February 2019 23:48:53 Dima Kogan wrote:
> Ethan A Merritt <sf...@us...> writes:
> 
> > That's not the development model we have been using.
> >
> > Trivial bug-fixes are applied for both the stable and development branches
> > immediately as they are found.
> >
> > Non-trivial changes, even bug fixes, are applied only to the
> > development branch. Often people using the development branch then
> > report related issues that require additional fixes or re-thinking of
> > the original fix. After sufficient testing in the development version
> > the original fix and any follow-ups developed during testing may or
> > may not be back-ported to the stable branch. This particular change
> > was non-trivial to begin with and engendered many follow-up fixes.
> 
> OK. Is your thinking to include this in a 5.4 release at some point in
> the future?

Sure.  
The development model is that at some point a branch-5-4-stable
is created from the development branch (_not_ from branch-5-2-stable).
It will obviously contain everything that has gone into the development
branch prior to that point.
- The old stable branch becomes a dead end.
- The new stable branch is used to prepare release packages.
- Development continues in the main branch.


[snip]
> i.e. there were 224 commits that appear in both master..5.2.6 AND in
> 5.2.6..master. Taking a random one. Look at this:
> 
>   gitk 1f7160945 fb107d74e
> 
> These are clearly the same commit, so ideally it should appear on
> neither "git log master..5.2.6" nor "git log 5.2.6..master", but it
> appears on both. Those commits aren't in a merge, and their immediate
> parents aren't the same. How did we get here? Did we cherry-pick it?

Yes.  Patch applied and tested in the development branch, later cherry-picked
for the stable branch.

> > The thing is, you can't go back to edit old commit messages like you
> > can edit a ChangeLog. That means you cannot fix typos, cannot clarify
> > or expand bad descriptions, cannot update or redact Email addresses,
> > cannot forward-link to eventual reversion or to subsequent related
> > patches etc.
> >
> > My #1 suggestion for improving git would be to move all the commit
> > messages to a parallel data structure so that they can be edited
> > without invalidating the orginal commit hash.
> 
> Are you really proposing to have a hand-curated NEWS file AND a
> hand-curated ChangeLog AND version control?

I would much rather that git maintained the ChangeLog automatically,
but so far as I have been able to learn it cannot be persuaded to do that.
The NEWS file is a bullet-point summary where each bullet point may
summarize many commits.  How would you get that other than manual
curation?  It might be more conventional to call it ReleaseNotes rather than NEWS.

	still willing to learn

		Ethan

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

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.

Re: Unreleased fixes in master

[Ethan A M. <sf...@us...>]

On Friday, February 22, 2019 12:52:24 PM PST Tait wrote:
> > ...
> > 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)

This has already diverged from my notion of "stable branch".
For me, anything in "stable" either is already in the master or will
never be there.  In no case will something move from stable to
master.

[snip]
 
> 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. 

Exactly.
This seems like a hint either that "git log" is the wrong tool
or that it could be improved by tracking a bit more history.
Can't the cherry-pick operation itself be recorded as a transaction?
Then a hypothetical command option "git log --show-origin"
would list  entries as

%%%
[4] git status
On branch branch-5-2-stable

[5] git log --show-origin HEAD~1..HEAD

commit d83adc16f5a572f5d004963ead8326591498dd41
Author: Ethan A Merritt <merritt@u.washington.edu>
Date:   Tue Feb 19 23:10:08 2019 -0800
Origin:  cherry-pick from master/83a349a07b3f30d3f0c11ff80152f3cb96ff3c77

    <body of commit message text>
%%%

Compared to everything else being tracked already, that seems
like it would be a trivial change with nice benefits. 

[snip]

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

I assumed this was the case.
But the thing is, security measures only make sense in the context
of a particular threat model.   I am far less concerned about the
possibility of authorized but malicious contributors corrupting the
history than I am about the presence of typos, errors, and outdated
or mistaken information in the history that cannot be corrected. 
To me the benefit from being able to edit the commit messages
outways the risk of deliberate corruption.
The edit history itself could be tracked, reviewed, and undone if
necessary in the case of corruption.  


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

I have to concede that point.  Consistent synchronization at the level
of the entire project definitely beats timestamps on individual files.

	Ethan

Re: Unreleased fixes in master

[Ethan A M. <sf...@us...>]

On Friday, February 22, 2019 1:57:37 PM PST Ethan A Merritt via gnuplot-beta wrote:

> Exactly.
> This seems like a hint either that "git log" is the wrong tool
> or that it could be improved by tracking a bit more history.
> Can't the cherry-pick operation itself be recorded as a transaction?
> Then a hypothetical command option "git log --show-origin"
> would list  entries as
> 
> %%%
> [4] git status
> On branch branch-5-2-stable
> 
> [5] git log --show-origin HEAD~1..HEAD
> 
> commit d83adc16f5a572f5d004963ead8326591498dd41
> Author: Ethan A Merritt <merritt@u.washington.edu>
> Date:   Tue Feb 19 23:10:08 2019 -0800
> Origin:  cherry-pick from master/83a349a07b3f30d3f0c11ff80152f3cb96ff3c77
> 
>     <body of commit message text>
> %%%

After some delving I have discovered that this used to be the default in git
but for some reason it was removed!   

The current documentation suggests that "git cherry-pick -x" may save the
history I want.  So I will use that going forward.

    thanks for putting up with my incomplete progress as a git user

		Ethan

Re: Unreleased fixes in master

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

Ethan A Merritt <sf...@us...> said (on 2019/02/22):
> After some delving I have discovered that [cherry-pick -x] used to be the
> default in git but for some reason it was removed!   
> 
> The current documentation suggests that "git cherry-pick -x" may save the
> history I want.  So I will use that going forward.

A cherry-pick could come from an entirely different repository
(added as a remote), and with -n and the possibility of
conflict, what's committed might not be the same as what was
picked, so I'd speculate that's why -x was dropped from being a
default.

The -x adds a "(cherry picked from commit hhhh...)" to the
commit message. It may be useful for humans, but I'm not aware
of anything that automatically processes the added comment. That
is, git log will still show the cherry-picked commit in both
master..stable and stable..master.

There is another tool, though, and I should have mentioned it
earlier but forgot it until now: git cherry. I think it's
exactly what Dima wants. And in poking at git-cherry, I learned
that git-log actually has options for this, too, now. So I think
we could have solved the problem without even needing this
discussion.

I'll let you read about git-cherry, but here's the git-log
version:
  git log --left-right --graph --cherry-mark --date-order \
      --oneline branch-5-2-stable...master
  # note, three dots, not two. See "dotted range notations"
  # under man git-rev-parse for details

  = 0a7b9a57e (origin/branch-5-2-stable, branch-5-2-stable)
              pm: restore binary backward compatibility for s...
  = 4146f1db2 pm: ignore alpha channel of RGBA colors
  = e73c08cb2 pm: reinitialize font on codepage change
  = 017c230c6 pm: remove help text of obsolete options
  = ca06c4ea1 Add a block for OS/2 code
  = fad43b5ad Fix glitch in toolbar icons on qt terminal
  | = 7bd40380f (HEAD -> master, origin/master, origin/HEAD)
  |             Fix glitch in toolbar icons on qt terminal
  | > ef90e907b new function trim(" padded string ") strips l...
  | > b83c88bb8 Parse numeric timezone UTC offset (format %z)...
  < | f5585bdb0 Extend the conditions under which ungetc() is...
  | = 32c048991 pm: restore binary backward compatibility for...
  | = 28d0fe668 pm: ignore alpha channel of RGBA colors
  | = 2446baa32 pm: reinitialize font on codepage change
  | > 6ac277288 pm: the EAM_BOXED_TEXT conditional is gone
  | = 47d2f151e pm: remove help text of obsolete options
  ... etc ...

You'll notice all the common cherry-picked commits are now
marked with =. By changing --cherry-mark to --cherry-pick
--right-only, they will be entirely excluded and only the
un-picked commits on the master side will be shown:

  * ef90e907b new function trim(" padded string ") strips lea...
  * b83c88bb8 Parse numeric timezone UTC offset (format %z) ...
  * 6ac277288 pm: the EAM_BOXED_TEXT conditional is gone
  ...

In all, I believe that makes 831 commits on master not on branch-5-2-stable.