Junio C Hamano wrote: > Felipe Contreras <felipe.contreras@xxxxxxxxx> 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 -- 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