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
'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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to