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

Re: What's cooking in git.git (May 2009, #02; Sun, 17)

From
Johan Herland <johan@herland.net>
Date
May 18, 2009, 21:55 UTC
Message-ID
<200905182355.21645.johan@herland.net>
In-Reply-To
<200905182140.29953.markus.heidelberg@web.de>
On Monday 18 May 2009, Markus Heidelberg wrote:
Show 23 quoted lines
> Johan Herland, 18.05.2009:
> > On Sunday 17 May 2009, Junio C Hamano wrote:
> > > [Will merge to "master" soon]
> > >
> > > * ph/submodule-rebase (Fri Apr 24 09:06:38 2009 +1000) 1 commit
> > >  + git-submodule: add support for --rebase.
> >
> > [..]
> >
> > Now, my question should not stop this feature from going into 'master',
> > except for the fact that if we also want to support merge, we should
> > rename the associated config variable:
> >
> > Instead of
> >
> >   submodule.<name>.rebase = true/false (false if unset)
> >
> > we should have something like
> >
> >   submodule.<name>.resolve = checkout/rebase/merge (checkout if unset)
>
> At least this would be inconsistent with options like
> branch.<name>.merge and branch.<name>.rebase

No. We cannot "reuse" the branch.<name>.merge/rebase semantics in this case: branch.<name>.merge takes a remote branch name to merge with, while submodule.<name>.merge needs no such name (the merge is well-specified without that extra name: the new submodule commit is merged into the submodule's current branch). Thus, submodule.<name>.merge is reduced to a simple bool indicating whether or not we should merge. At this point, however, it is not only inconsistent with branch.<name>.merge, it also directly conflicts with submodule.<name>.rebase (they cannot both be "true" simultaneously). They should therefore be collapsed into one tri-state config variable set to either 'rebase', 'merge' or 'false'/unset (which triggers the default 'checkout' behaviour). This is pretty much what I propose above.

After some thinking, I don't like my original name submodule.<name>.resolve, since ".resolve" sounds more like a merge strategy or conflict resolution method, than a "how to deal with submodule update" choice. I propose submodule.<name>.update instead.

...Johan
-- 
Johan Herland, <johan@herland.net>
www.herland.net
Previous: Markus HeidelbergNext: Johan Herland
Message 8 of 23 in “What's cooking in git.git (May 2009, #02; Sun, 17)”
  1. Junio C HamanoMay 17, 2009
  2. Jakub NarebskiMay 17, 2009
  3. Junio C HamanoMay 17, 2009
  4. Jakub NarebskiMay 17, 2009
  5. David AguilarMay 17, 2009
  6. Johan HerlandMay 18, 2009
  7. Markus HeidelbergMay 18, 2009
  8. Johan HerlandMay 18, 2009
  9. git-submodule: add support for --merge.Johan Herland, May 19, 2009
  10. Junio C HamanoMay 19, 2009
  11. Johan HerlandMay 19, 2009
  12. Johannes SchindelinMay 19, 2009
  13. Johan HerlandMay 19, 2009
  14. Johannes SchindelinMay 19, 2009
  15. Johan HerlandMay 19, 2009
  16. Johan HerlandMay 25, 2009
  17. Junio C HamanoMay 25, 2009
  18. Johannes SchindelinMay 25, 2009
  19. Avery PennarunMay 25, 2009
  20. Johannes SchindelinMay 25, 2009
  21. Johan HerlandMay 25, 2009
  22. Johan HerlandMay 25, 2009
  23. Peter HuttererMay 25, 2009

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.