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

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].


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?)


  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 [this message]
2017-12-21 22:17               ` Andreas Urke
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 \ \ \ \ \ \

* 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