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 name. 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. Regards, Andreas On 21 December 2017 at 19:55, Stefan Beller <sbeller@xxxxxxxxxx> wrote: > On Thu, Dec 21, 2017 at 8:21 AM, Andreas Urke <arurke@xxxxxxxxx> 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] https://www.kernel.org/pub/software/scm/git/docs/gitsubmodules.html > [2] https://www.kernel.org/pub/software/scm/git/docs/git-submodule.html > [3] https://www.kernel.org/pub/software/scm/git/docs/gitmodules.html > > 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
