mailing list mirror (one of many)
 help / Atom feed
From: Andreas Urke <>
To: Stefan Beller <>
Cc: Junio C Hamano <>, git <>
Subject: Re: [PATCH] Re: Bug with "git submodule update" + subrepo with differing path/name?
Date: Thu, 21 Dec 2017 23:17:18 +0100
Message-ID: <> (raw)
In-Reply-To: <>

Thanks for the detailed explanation. Although I am not too git savvy,
I believe I got the gist of it.

Regarding your question,
I would say the term "name" in an IT context makes me primarily think
of something that is specified by a user (as opposed to e.g. an "id"),
and can be altered by a user. Also, the manual mention it as a
"logical name", which would further strengthen my belief that it is an
abstraction which can be changed (as opposed to something "physical").
I would be much more reluctant to change the id of something than its

In terms of the commands...In an ideal world I would obviously ask for
a --rename or mv command which would achieve what I wanted to do.
Other than that, maybe a word about this in the man for "git mv"? Or
perhaps "git submodule sync" could give me some kind of warning that I
did something strange/illegal.

Can I ask you, now that I have made this mess, do you have any
suggestion on how to rectify it or some other way to achieve my goal?
The only side-effect I have seen is this update problem (been running
this for a few months), but after your explanations I would like to
get back to solid ground. My use-case is that I need to follow a
specific folder-naming (i.e. subrepo path) convention, but I do not
want to use that naming as the repo name in our gitlab.


On 21 December 2017 at 19:55, Stefan Beller <> wrote:
> On Thu, Dec 21, 2017 at 8:21 AM, Andreas Urke <> wrote:
>> If I am entering into undefined behavior territory with the renaming
>> then there might not be any point to pursue this further, but in any
>> case, script below:
>> Apologies up-front for the verbosity, there are probably a lot of
>> unnecessary steps and git shortcuts missed - I just wanted it to
>> exactly match my scenario. Note that it is divided into two parts as
>> it requires you to edit .gitmodules.
>> Part 1:
>> cd ~/
>> # Make sub repos and add a commit to each
>> mkdir super && cd super
>> mkdir sub1 && mkdir sub2
>> cd sub1
>> git init && touch first && git add . && git commit -m "first"
>> cd ../sub2
>> git init && touch first && git add . && git commit -m "first"
>> cd ..
>> # Make super repo, add subrepos, and commit
>> git init
>> git submodule add ./sub1
>> git submodule add ./sub2
>> git add .
>> git commit -m "first"
>> # Edit .gitmodules, change sub2 name and path to sub2_newname:
>> # $ cat .gitmodules
>> # [submodule "sub1"]
>> # path = sub1
>> # url = ./sub1
>> # [submodule "sub2_newname"]
>> # path = sub2
>> # url = ./sub2_newname
> A couple of things here:
> (a) In a script you could do this via
>     git config -f .gitmodules --rename-section <old> <new>
> (b) This is not just undefined, but rather Git explicitly assumes
>     the user does not rename the section themselves.
> The reason for this is found in gits history:
> 1. submodules were invented
> 2. submodule configuration such as where to obtain
>     the submodule from needs some place, and at the time
>     submodule.<path>.url inside the .gitmodules file seemed
>     like a good idea.
> 3. "What if we want git-mv, git-rm support for submodules?"
>     Or for example when bisecting and jumping between revisions
>     where the submodule exists or does not exists. To solve
>     this problem, the concept of a "submodule name" was invented,
>     such that the submodules git dir can be put into the
>     superprojects .git/modules/<name> dir, and the working tree
>     only needs to have a ".git" file pointing at that gitdir. The the
>     working tree of the submodule can be removed while keeping
>     the submodules git dir (with potentially important information
>     such as local-only commits) around! Success!
>     The transition path is also easy:
>     These newly "named" submodules have an additional entry of
>     'submodule.<name>.path =<path>'. Note how the subsection
>     part of the config changed its meaning, but that is ok, as the
>     name is allowed to be equal to the <path> value, and keeps
>     all config related to one submodule in one section. Easy but
>     confusing as now we have to adhere to a couple assumptions:
>     The <path> value must match where it is in the working tree,
>     the <name> however must not be changed because that is
>     where we'll find its repository inside the superproject.
>     And confusingly these two keys have often the same value,
>     for this historic reason.
> 4. (rather lately): We need to fix the submodule mess.
>     While in (3) we were unclear about name/path issues,
>     and tried to be super backwards compatible, now we'd
>     rather want the submodules to be well-defined. So we'll
>     try to write some docs, such as gitsubmodules [1] in addition
>     to the usage manual of "git submodule"[2]. Of course there is
>     still the description of the .gitmodules file[3].
> [1]
> [2]
> [3]
> I guess in [1] we'd want to add a discussion on what the <name> and
> what the <path> is for and why one can change but not the other.
> I think you ran into trouble here because you and Git had
> differing assumptions on some part of the submodule model.
> Is there any part of the documentation, configuration or some
> commands that would have helped explaining some of these things?
> (i.e. What do we best patch to help others from running into the
> same issue?)
> Thanks,
> Stefan

  reply index

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-18 23:18 Andreas Urke
2017-12-19 18:02 ` [PATCH] " Stefan Beller
2017-12-19 22:19   ` Junio C Hamano
2017-12-19 22:33     ` Stefan Beller
2017-12-20  8:22       ` Andreas Urke
2017-12-20 17:54         ` Stefan Beller
2017-12-21 16:21           ` Andreas Urke
2017-12-21 18:55             ` Stefan Beller
2017-12-21 22:17               ` Andreas Urke [this message]
2017-12-21 23:08                 ` Stefan Beller
     [not found]               ` <>
2017-12-21 22:57                 ` Stefan Beller

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link mailing list mirror (one of many)

Archives are clonable:
	git clone --mirror
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

Newsgroups are available over NNTP:

 note: .onion URLs require Tor:
       or Tor2web:

AGPL code for this site: git clone public-inbox