From: Junio C Hamano <gitster@pobox.com>
Date: Thu, 26 Feb 2015 23:51:57 GMT
Subject: Re: Any chance for a Git v2.1.5 release?
Message-ID: <xmqqpp8wjko2.fsf@gitster.dls.corp.google.com>
In-Reply-To: <35E11B78-6FF8-41DE-BBF5-8978DA2F87A6@gmail.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-<.