Re: [ANNOUNCE] git reintegrate v0.3; manager of integration branches

> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> I'm not sure what would be the usefulness of using things like
>> 'xx/topic~4'.
>
> As a notation it is not very pretty ;-).
>
> Imagine that xx/topic is about a multistep introduction of a
> backward incompatible feature.  The beginning part of the series up
> to xx/topic~4 are the step to start warning (i.e. "will change---do
> this to keep the old one or do that to live in the future"),
> xx/topic~3..xx/topic~1 are the next step to flip the default and
> still keep warning (i.e. "have changed---do this to keep the old one
> or do that to live in the present"), and the final xx/topic is the
> endgame where everybody lives with the new default with no warning,
> without having to know what the old default was.
>
> While the topic is being prepared for the next release, the insn
> sheet for 'jch' would have xx/topic~4 before "match next" marker,
> and then an entry for xx/topic~1 somewhere after it, and finally an
> entry for xx/topic (i.e. the tip, final commit).  When the first
> step cooked well enough in 'next', selected entries of 'jch' insn
> sheet before "match next" ones are used to merge them to 'master'
> and the part up to xx/topic~4 (but not later patches on the topic
> branch) will be part of the upcoming release.
>
> You could simulate that with multiple branches stacked on top of
> each other, but there are times when keeping things together in a
> single branch is more handy.
>
> In restrospect, if I found xx/topic~4 too ugly, I might have instead
> made "branches stacked on top of each other" easier to manage, but
> having Reintegrate support "in the middle of a branch" was simpler.
> They are both OK solutions to the same problem, and I didn't have to
> solve it both ways ;-)