git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Felipe Contreras <felipe.contreras@gmail.com>
Date
May 20, 2014, 21:06 UTC
Message-ID
<537bc3e1c605c_a6f166b3088f@nysa.notmuch>
In-Reply-To
<xmqqha4lxyqt.fsf@gitster.dls.corp.google.com>
Junio C Hamano wrote:
Show 44 quoted lines
> 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
Previous: Junio C HamanoNext: Junio C Hamano
Message 3 of 9 in “[ANNOUNCE] git reintegrate v0.3; manager of integration branches”
  1. Felipe ContrerasMay 19, 2014
  2. Junio C HamanoMay 19, 2014
  3. Felipe ContrerasMay 20, 2014
  4. Junio C HamanoMay 20, 2014
  5. Felipe ContrerasMay 20, 2014
  6. Junio C HamanoMay 20, 2014
  7. Felipe ContrerasMay 20, 2014
  8. Felipe ContrerasMay 24, 2014
  9. Felipe ContrerasMay 24, 2014

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.