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

Re: [PATCH] Teach git submodule update to use distributed repositories

From
Johannes Schindelin <johannes.schindelin@gmx.de>
Date
Jul 17, 2008, 12:58 UTC
Message-ID
<alpine.DEB.1.00.0807171351380.8986@racer>
In-Reply-To
<320075ff0807170521s26693381m60648468cce1c41c@mail.gmail.com>
Hi,
On Thu, 17 Jul 2008, Nigel Magnay wrote:
Show 12 quoted lines
> On Thu, Jul 17, 2008 at 1:13 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>
> > On Thu, 17 Jul 2008, Nigel Magnay wrote:
> >
> >> When doing a git submodule update, it fetches any missing submodule 
> >> commits from the repository specified in .gitmodules.
> >
> > Huh?  It takes what is in .git/config!  Not what is in .gitmodules.
> 
> Huh? And where does .git/config get it from? Oh, that's right, 
> .gitmodules.

Oh, that's right, after "git submodule init". Right before you are supposed to change them if your setup commands that.

Show 6 quoted lines
> > So if you have another remote (or URL, e.g. if you have ssh:// access, 
> > but the .gitmodules file lists git://), just edit .git/config.
> 
> So for my usecase, you'd have me go in and change *evey single one* of 
> my submodule refs from the centralised repository, *every time* I want 
> to do a peer review?
No.
> Doesn't the current system strike you as being somewhat centralised in 
> nature?
No.
Show 5 quoted lines
> > I meant, that is the whole _point_ of having a two-step init/update 
> > procedure.
> 
> Are you just determined that submodules should remain useless for "the 
> rest of us"?
No.

If you really need to change the "origin" back and forth between reviews, while the committed state of the superproject stays the same, then something is seriously awkward and needs to be streamlined in your setup.

Because when the superproject's revision stays the same, "git submodule update" may fetch additional objects if you specify another remote, but it will check out just the same revisions of the submodules. Because they were committed as such.

But if you want to get objects from another server (as opposed to update the submodules' working directories to the latest committed revisions), which happens to have the identical layout of the principal server (which I would deem another setup peculiarity to be fixed), you might want to look into the recurse patch that was flying about on this list a few months back.

Hth, Dscho

Previous: Nigel MagnayNext: Nigel Magnay
Message 5 of 23 in “Teach git submodule update to use distributed repositories”
  1. Teach git submodule update to use distributed repositoriesNigel Magnay, Jul 17, 2008
  2. Johannes SchindelinJul 17, 2008
  3. Petr BaudisJul 17, 2008
  4. Nigel MagnayJul 17, 2008
  5. Johannes SchindelinJul 17, 2008
  6. Nigel MagnayJul 17, 2008
  7. Johannes SchindelinJul 17, 2008
  8. Nigel MagnayJul 17, 2008
  9. Petr BaudisJul 17, 2008
  10. Nigel MagnayJul 18, 2008
  11. Jakub NarebskiJul 18, 2008
  12. Junio C HamanoJul 18, 2008
  13. Jakub NarebskiJul 18, 2008
  14. Nigel MagnayJul 18, 2008
  15. Petr BaudisJul 18, 2008
  16. Nigel MagnayJul 18, 2008
  17. Petr BaudisJul 18, 2008
  18. Nigel MagnayJul 18, 2008
  19. Petr BaudisJul 18, 2008
  20. Nigel MagnayJul 18, 2008
  21. Petr BaudisJul 18, 2008
  22. Mark LevedahlJul 18, 2008
  23. Nigel MagnayJul 21, 2008

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.