On Tue, May 20, 2014 at 5:47 PM, Junio C Hamano <gits...@pobox.com> wrote:
> Felipe Contreras <felipe.contre...@gmail.com> writes:
>> I'm not sure what would be the usefulness of using things like
> 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 ;-)
Yes, I see how xx/topic~4 would be useful in the instruction sheet, I
just didn't see it would be useful to generate that from an existing
integration branch. After the explanation above I see how it could be
useful to some people (though not all). I'll implement that.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html