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

Re: Re: Relative submodule URLs

From
Heiko Voigt <hvoigt@hvoigt.net>
Date
Aug 19, 2014, 19:30 UTC
Message-ID
<20140819193010.GA64203@book.hvoigt.net>
In-Reply-To
<CAHd499B9Wa=Y6P+OD8Ea-6dA4yZSkGZZSR9CwZAM45evDL_Qiw@mail.gmail.com>
On Tue, Aug 19, 2014 at 11:50:08AM -0500, Robert Dailey wrote:
Show 24 quoted lines
> Maybe I'm misunderstanding something here and you can help me out.
> 
> All the reading I've done (mostly github) says that 'upstream' points
> to the authoritative repository that you forked from but do not have
> permissions to write to. 'origin' points to the place you push your
> changes for pull requests (the fork).
> 
> Basically the workflow I use is:
> 
> - Use 'upstream' to PULL changes (latest code is obtained from the
> authoritative repository)
> - Use 'origin' to push your branches. Since I never modify the
> branches that exist in 'upstream' on my 'origin' (I do everything
> through separate personal branches).
> 
> That means if I have a branch off of 'master' named 'topic', I will
> track 'upstream/master' and get latest with 'git pull'. When I'm ready
> for a pull request, I do 'git push origin' (I use push.default =
> simple).
> 
> According to my understanding, relative submodules work here. But not
> everyone on my team uses this workflow. Sometimes they track
> "origin/topic" (if we use my example again). Won't the submodule try
> to find itself on the fork now?

Well the remote for the submodule is currently only calculated once, when you do the initial

	git submodule update --init

that clones the submodule. Afterwards the fixed url is configured under the name 'origin' in the submodule like in a normal git repository that you have freshly cloned. Which remote is used for cloning depends on the configured remote for the current branch or 'origin'.

When you do a fetch or push with --recurse-submodules it only executes a 'git fetch' or 'git push' without any specific remote. For fetch the same commandline options (but only the options) are passed on.

Here it might make sense to guess the remote in the submodule somehow and not do what fetch without remotes would do.

For the triangular workflow not much work has been done in regards to submodule support.

But since a submodule behaves like a normal git repository maybe there is not much work needed and we can just point to the workflow without submodules most times. We still have to figure that out properly.

Cheers Heiko
Previous: Robert DaileyNext: Robert Dailey
Message 9 of 25 in “Relative submodule URLs”
  1. Robert DaileyAug 18, 2014
  2. Jonathan NiederAug 18, 2014
  3. Heiko VoigtAug 19, 2014
  4. Robert DaileyAug 19, 2014
  5. Junio C HamanoAug 19, 2014
  6. Robert DaileyAug 19, 2014
  7. Junio C HamanoAug 19, 2014
  8. Robert DaileyAug 19, 2014
  9. Heiko VoigtAug 19, 2014
  10. Robert DaileyAug 19, 2014
  11. Heiko VoigtAug 19, 2014
  12. Robert DaileyAug 20, 2014
  13. Heiko VoigtAug 21, 2014
  14. Robert DaileyAug 19, 2014
  15. Marc BranchaudAug 22, 2014
  16. Heiko VoigtAug 24, 2014
  17. Robert DaileyAug 25, 2014
  18. Robert DaileyAug 25, 2014
  19. Heiko VoigtAug 26, 2014
  20. Robert DaileyAug 26, 2014
  21. Heiko VoigtAug 26, 2014
  22. Robert DaileyAug 25, 2014
  23. Marc BranchaudAug 28, 2014
  24. Heiko VoigtAug 28, 2014
  25. Marc BranchaudAug 29, 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.