Re: [ANNOUNCE] git reintegrate v0.3; manager of integration branches

[Felipe Contreras <felipe.contreras@gmail.com>]

Junio C Hamano wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
> 
> > ...
> > Which will generate the integration instructions for you:
> >
> >   % git reintegrate --cat
> >   base master
> >   merge jl/submodule-mv
> >
> >     Moving a regular file in a repository with a .gitmodules file was
> >     producing a warning 'Could not find section in .gitmodules where
> >     path=<filename>'.
> >
> >   merge ap/remote-hg-unquote-cquote
> >
> > It also has support for "evil merges", so it should be perfectly
> > usable for git.git maintenance.
> 
> Yeah, it sounds like it is almost there.
> 
> I think the infrastructure to maintain "What's cooking" could be
> updated to use these comments after "merge" instructions if I wanted
> to.
> 
> I build two branches on top of 'master', one is called 'jch' and has
> a marker line somewhere that says '### match next' that is turned
> into an empty commit, and 'pu' that is built on top of the tip of
> 'jch'.  The marker line is used to apply only an earlier part of the
> instruction stream to build 'jch' on top of 'master' on top of
> 'next' (i.e. "base master" in the above example will not be applied
> to hard-reset 'next' to match master) and stop there, and is meant
> to be a way to sanity check 'next' (which is made by repeated
> incremental merges on top of 'master' without rewinding) by
> comparing the "### match next" commit between 'master' and 'jch'
> (which is made afresh from 'master' by taking only the necessary
> topics).  They must match or I caught a possible mismerge on 'next'.
> 
> I presume that the workflow can be mimicked by having another branch
> 'match-next' and building it on top of 'master', and then building
> 'jch' on top of it, and then building 'pu' on top of it.  Then you
> should be able to play 'match-next' instruction on top of 'next'
> (provided that there is a way to tell it to replay on HEAD and
> ignore "base" and have "merge" instruction become a no-op when the
> branch has already been merged)

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.

I would have two branches: 1) 'match-next' (or 'integration-next') that
has the instructions to build 'next' on top of 'master', and 2) 'pu',
which has the instructions to build 'pu' on top of 'next'.

-- 
Felipe Contreras