"Kyle J. McKay" <mackyle@xxxxxxxxx> 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-<.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html