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

Git submodule regression in 2.7.0+

From
CJCaleb Jorden <cjorden@gmail.com>
Date
Feb 24, 2016, 19:35 UTC
Message-ID
<CABD8wQkN8bLQzqtUru9X+Mxji8U4UoUVdiioCNrJsWEzwcL50g@mail.gmail.com>
Git community,

I have hit a rather significant regression in recent versions of Git, when using submodules. I have narrowed it down to a simple set of commands that demonstrates the problem (commands for a unix-style OS):

---- Start list of commands to reproduce issue ---- mkdir -p test/a/b cd test git init cd a/b git init echo hello > testfile1 git add . git commit -m "test1" cd ../.. mkdir -p 1/b cd 1/b git init echo hi > testfile2 git add . git commit -m "test2" cd ../.. git submodule add /a/b a/b git submodule add /1/b 1/b git commit -m "first submodule commit" git submodule--helper list a/b ---- End list of commands ----

On my machines, this shows 1/b, not a/b.

It seems that the submodule--helper (at least for the list command) is not properly taking into account the path in the repository, but rather just the submodule name itself.

This manifests itself if you have a Git repo that uses submodules that has been updated (or just cloned), and you want to specifically update a single submodule (which is where this problem was discovered). If you run in "git submodule update <submodule path>", and you have two submodules with the same name (but in different paths in the repository), then you will update the first one found (lexicographically, as far as I can tell), every time. There may be other operations on submodules that are impacted as well, but I have not explored them completely.

This may seem like a contrived situation, but this problem was found in a live repo that uses submodules (albeit a private one).

Note that this behavior changed in 2.7.0 and is still current (happens in 2.7.1, 2.7.2, and master in git repo as of 2/23/2016). Prior to 2.7.0 (which introduced the submodule--helper command) the behavior for this was as expected - the entire path was taken into account for the submodule update command. This has been observed on a Gentoo machine (x86_64), as well as numerous Ubuntu installs (x86_64, 14.04). This occurs both with the ubuntu git PPA (Git stable releases "Ubuntu Git Maintainers" team, 2.7.1 at the time of this writing) and from a fresh compile of 2.7.2 from source.

This regression can be fixed in 2.7.2 if one reverts the three commits which introduced submodule--helper.c file and associated changes (ee8838d157761acf4cc38f2378277dc894c10eb0, 0ea306ef1701d6f42e74d3c33addfcd630248904, and 74703a1e4dfc5affcb8944e78b53f0817b492246). Just to be clear, I am not advocating reverting these changes - I would rather see the submodule--helper.c work continue, but also see this fixed.

I have not yet had the time to dive into the code to find what the problem is, but I wanted to make sure this was reported so that others who may be hitting this can be aware of it. Also, I wanted to make Stefan Beller aware of this, as he seems to still be working on the submodule--helper.c code.

I am not currently subscribed to the Git mailing list, so please CC me in any response.

Regards,

Caleb Jorden cjorden@gmail.com

Next: Stefan Beller
Message 1 of 2 in “Git submodule regression in 2.7.0+”
  1. Caleb JordenFeb 24, 2016
  2. Stefan BellerFeb 24, 2016

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.