Felipe Contreras [off-list ref] 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).
Fun.
Junio C Hamano wrote:
Felipe Contreras [off-list ref] writes:
quoted
...
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
Junio C Hamano wrote:
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).
Done.
% git checkout next
% git reintegrate --apply match-next
https://github.com/felipec/git-reintegrate/commit/036395b
--
Felipe Contreras