Junio C Hamano wrote: > Felipe Contreras <felipe.contreras@xxxxxxxxx> writes: > > > Or have an option to specify a dynamic instruction sheet, so you can cat > > the instructions of 'match-next' and replace the base. However, I don't > > see the point of re-applying the branches for 'next' if you already know > > that 'next' and 'match-next' are the same. > > The output from Reintegrate script (in 'todo') only lists the names > of topic branches (or something like "xx/topic~4" when the topic is > not fully merged yet), and a topic branch may acquire a follow-up > change (or two) on top (there is a machinery to see if xx/topic~4 > is still valid in such a case and update the offset as needed). > > Rebuilding 'jch' on top of 'master' with the same insn sheet will > then merge the updated topic branch in its entirety, and the new > commits on the topic branch somehow needs to go to 'next' for the > "match next" on 'jch' and 'next' to be in sync (in addition, updated > 'master' must be merged to 'next', but that goes without saying). > > In other words, I already know that 'next' and "match next" are not > the same, that they must become the same, and there needs a way to > make them so. > > And that is done by re-running the insn sheet for 'jch' up to the > "match next" mark, merging the topic that are not fully merged to > 'next' while ignoring the ones that already are fully in 'next'. There could be a new --merge-missing option that takes the instruction sheet of an integration branch (e.g. 'match-next'), ignores the 'base' applies them in 'HEAD' but only when the topic branch isn't already in 'HEAD'. I'm not sure what would be the usefulness of using things like 'xx/topic~4'. -- 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