Re: Any chance for a Git v2.1.5 release?

[Junio C Hamano <gitster@pobox.com>]

"Kyle J. McKay" <mackyle@gmail.com> writes:

>> After finishing 2.3.0 release, at some point while 'master' is still
>> at 2.3.0, something like this would happen:
>>
>>    $ git branch -m maint maint-2.2
>>    $ git branch maint master
>
> So the reason I don't notice force-updates to maint when this happens
> is because of the "Sync with maint" commits that make sure the new
> maint contains the old one.

I could also do

    git branch maint-2.2 maint
    git push . master:maint ;# not +master:maint

to make sure that I won't rewind 'maint', but this works because
'master' is designed to be always a super-set of 'maint'.

> If I were to keep a maint-lts branch somewhere I would need to cherry- 
> pick topics with desired fixes that fall into that situation.  That's
> what I expected but when you mentioned down merging the fixes I wanted
> to make sure I wasn't overlooking something.

Yup.  I _can_ become sloppy especially late in the release cycle and
end up doing something silly like this:

    - Fork km/svn-fix from somewhere it _could_ be merged to 'maint'
      (e.g. "the last big release", e.g. v2.3.0).

    - Merge km/svn-fix to 'master' early in a cycle;

    - A mistake is found in the topic late in the cycle; as the next
      release will happen soon _anyway_, and I do not happen to
      consider km/svn-fix is so important a fix to be merged to
      'maint', I apply a fix-up patch directly on top of 'master';

    - A release candidate is tagged from 'master'.

Then even though you can easily grab a broken-out tree at
github.com:gitster/git, km/svn-fix topic alone cannot be merged to
'maint' as it would lack the late fix.  I've been trying to be
careful but I cannot promise to be perfect X-<.