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

Re: A design for subrepositories

From
LALauri Alanko <la@iki.fi>
Date
Oct 14, 2012, 22:59 UTC
Message-ID
<20121015015934.1597359e76eaqvh2.lealanko@webmail.helsinki.fi>
In-Reply-To
<507AE773.1010301@web.de>
Show 6 quoted lines
>> la@bq:~/tmp/super$ git mv sub movedsub
>> fatal: source directory is empty, source=sub, destination=movedsub
>
> This error here indicates that we didn't teach git to properly move
> a submodule yet. It is one of my next goals to make "git [submodule]
> mv sub movedsub" do the right thing here.

I'll digress here a bit: I'm not really fond of the idea of adding special-purpose support into the core git commands. It just makes them messier, and there will always be other tools that won't be supported by git directly. I'd much rather see an mv-hook that arbitrary extensions could use to update metadata associated with a tree entry.

Indeed, one of the reasons a separate tool seemed attractive to me was that that way I could be sure that the tool was a high-level utility that was completely implemented on top of basic low-level git operations. The fact that git's submodule support manifests as bits and pieces in various parts of the core seems a bit worrisome to me.

(Moreover, it's confusing to the user. I read the git-submodule man page and thought that that described all the available submodule operations. Only now did I find out that clone and fetch also have built-in submodule functionality.)

>> la@bq:~/tmp/super$ mv sub movedsub
>
> Currently it is better to remove the submodule here, as recreating it
> with a "git submodule update" later will get the relative paths right.

This was a bit of a special case, as this was the original directory where we did "git init sub" and "git submodule add ./sub". So "sub" actually contains the real repository, not a gitlink to .git/modules/sub. Arguably "git submodule add" should move the local submodule's repository there.

Show 6 quoted lines
>> la@bq:~/tmp/super$ git rm sub
>> rm 'sub'
>> la@bq:~/tmp/super$ git add movedsub
>
> And to git this adds a completely different submodule (as its name
> is not "sub"), which breaks your expectation.

Submodule? This is just a normal git add, not git submodule add. I thought this just adds to the index a gitlink with the head revision in movedsub, which is the same as the head revision was in sub, so it's detected as a move of a gitlink.

> To do what you intended
> use this line instead:
>
> $ git update-index --add --cacheinfo 160000 $HASH movedsub

Doesn't this do exactly the same thing as "git add" for a directory containing a repository?

Show 8 quoted lines
>> la@bq:~/tmp/superc$ git submodule update --init
>> Submodule 'sub' (/home/la/tmp/super/sub) registered for path 'sub'
>> fatal: repository '/home/la/tmp/super/sub' does not exist
>> Clone of '/home/la/tmp/super/sub' into submodule path 'sub' failed
>
> And that fails because to be able to clone a submodule it has to be
> pushed into its own repo first, so it can be cloned from there somewhere
> else. After doing that this will work.

Sorry, but I can't get this to work. To me it seems that when fetching submodules from the origin, submodule.sub.url has to point to the actual location of the repository, and if this is outdated or missing, the fetch won't work.

It would make sense that if the url is missing, the submodule repo inside origin's .git/modules would be used, but this doesn't seem to be the case currently.

> Currently "git fetch" checks all newly fetched commits for changes in
> gitlinks too, so that would just add another file to that.

I only now realized that it is indeed enough to check .gitmodules only in the _updated_ refs. The older refs are interested in their submodules only up to a certain commit, and even if those submodules have been updated upstream, we won't be interested in them until we have trees with gitlinks pointing to the newer revisions.

So it turns out that my main technical argument against git-submodule's potential scalability was false, and it is indeed feasible to make it support all the features I require.

However, "always tip" mode would break this, since then even non-updated branches might be interested in upstream changes to a submodule.

Anyway, I am a bit surprised to hear of such active development for git-submodule. It's pretty old now (the shell script says 2007), and I thought that if it were to ever support the kind of basic functionality I require, it would do so already.

How soon do you envision support for bare repositories with submodules?
Lauri
Previous: Jens LehmannNext: Jens Lehmann
Message 15 of 17 in “A design for subrepositories”
  1. Lauri AlankoOct 13, 2012
  2. Junio C HamanoOct 13, 2012
  3. Lauri AlankoOct 13, 2012
  4. Junio C HamanoOct 14, 2012
  5. Lauri AlankoOct 14, 2012
  6. Jens LehmannOct 14, 2012
  7. Lauri AlankoOct 14, 2012
  8. Jens LehmannOct 14, 2012
  9. Jens LehmannOct 14, 2012
  10. Jens LehmannOct 14, 2012
  11. Junio C HamanoOct 14, 2012
  12. Jens LehmannOct 14, 2012
  13. A design for distributed submodulesLauri Alanko, Oct 19, 2012
  14. Jens LehmannOct 19, 2012
  15. Lauri AlankoOct 14, 2012
  16. Jens LehmannOct 15, 2012
  17. perryh@pluto.rain.comOct 13, 2012

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.