On Wed, Jun 14, 2017 at 10:53:12AM -0700, Stefan Beller wrote: > >> In my ideal dream world of submodules we would have the following: > >> > >> $ cat .gitmodules > >> [submodule "sub42"] > >> path = foo > >> # path only in tree! > > > > TBH, I am not sure why we need "path"; couldn't we just use the > > subsection name as an implicit path? > > That is what was done back in the time. But then people wanted to rename > submodules (i.e. move them around in the worktree), so the path is not > constant, so either we'd have to move around the git dir whenever the > submodule is renamed (bad idea IMO), or instead introduce a mapping > between (constant name <-> variable path). So that was done. Ah, right. That makes sense. I forgot that in addition to the in-tree path, we have to store the submodule repository itself as some name. The extra level of indirection there isn't strictly necessary, but it lets the "name" act as a unique id. > Historically (IIUC) we had submodule.path.url which then was changed > to submodule.name.url + name->path resolution. And as a hack(?) or > easy way out of a problem then, the name is often the same as the path > hence confusing people, when they see: > > [submodule "foo"] > path = foo > url = dadada/foo > > What foo means what now? ;) Right, I am such a person that has been confused. ;) Thanks for explaining. > Talking about another tangent: > > For files there is a rename detection available. For submodules > It is hard to imagine that there ever will be such a rename detection > as files have because of the explciit name<->path mapping. > > We *know* when a submodule was moved. So why even try > to do rename detection? As we record only sha1s for a submodule > you could swap two submodule object names by accident. > Consider a superproject that contains different kernels, such as > a kernel for your phone/embedded device and then a kernel for > your workstation or other device. And these two kernels are different > for technical reasons but share the same history. Do you mean during the rename detection phase of a diff, check to see if .gitmodules registered a change in path for a particular module (by finding its entry in the diff and looking at both sides), and if so then mark that as a rename for the submodule paths? >From a cursory glance, that sounds like an interesting approach. -Peff