On Tue, May 20, 2014 at 5:47 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Felipe Contreras <felipe.contreras@xxxxxxxxx> 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 ;-) 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. -- Felipe Contreras -- 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