Re: as/safecrlf-quiet-fix, was Re: What's cooking in git.git (Jun 2018, #07; Thu, 28)

Johannes Schindelin [off-list ref] writes:

On Tue, 3 Jul 2018, Junio C Hamano wrote:

quoted

Johannes Schindelin [off-list ref] writes:

quoted

On Thu, 28 Jun 2018, Junio C Hamano wrote:

quoted

* as/safecrlf-quiet-fix (2018-06-11) 1 commit
  (merged to 'next' on 2018-06-13 at b163674843)
 + config.c: fix regression for core.safecrlf false

 Fix for 2.17-era regression around `core.safecrlf`.

Is this `maint` material?

Possibly.  Why do you ask?

This is my feeble attempt at helping you triage. My question was more like
a suggestion.

Ah, thanks.  That line of suggestion does help, and it would even be
more helpful when given before the topic hits 'next' or after
'master' from the workflow's point of view.

While the topic is in 'pu' I can change where the topic forks from,
and to minimize temptation to stupidly merge an inappropriate topic
(e.g. new developments and somewhat dubious fixes to commonly used
part of Git) down to 'maint' during the pre-release freeze
(i.e. when the tree is otherwise hopefully sleepily quiet and
boring), I try to base the (beginning of) good 'maint' material on
'maint' or older, and everything else on the tip of 'master' (or the
most recent feature release), when each topic is originally queued
in my tree.  If I missed a good topic and based it on 'master', it
is easier to correct such a mistake before it hits 'next', and a
suggestion like above would help me tremendously.

After the topic hits 'next', its course is pretty much set, until it
graduates to 'master'.  About a week or two after such event, I'd go
through "merge ... later to maint" entries in the draft release notes
and if the topic still looked relevant to the maintenance branch,
merge them to 'maint'.  Before that happens is another chance to stop
me from making a stupid mistake, or remind me of an urgent one that
I've been letting wait in 'master' before merging to 'maint'.

Thanks.