Junio C Hamano wrote:
> Felipe Contreras <felipe.contre...@gmail.com> 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

I'm not sure what would be the usefulness of using things like

Felipe Contreras
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

Reply via email to