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

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

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 ;-)