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