Am 06.03.2014 02:25, schrieb Henri GEIST: > Le mercredi 05 mars 2014 à 19:13 +0100, Jens Lehmann a écrit : >> Am 03.03.2014 21:34, schrieb Henri GEIST: >>> Le lundi 03 mars 2014 à 17:45 +0000, Jens Lehmann a écrit : >>>> Am 03.03.2014 14:47, schrieb Henri GEIST: >>>>> This new option prevent git submodule <add|update> to clone the missing >>>>> submodules with the --separate-git-dir option. >>>>> Then the submodule will be regular repository and their gitdir will not >>>>> be placed in the superproject gitdir/modules directory. >>>> >>>> And what is your motivation for this? After all submodules containing >>>> a .git directory are second class citizens (because they can never be >>>> safely removed by regular git commands). >>>> >>> >>> I recognize most people will prefer to have the .git directory separate. >>> And I do not intend to make this option the default. >>> >>> My reasons are: >>> >>> - As it is not clearly stated in the doc that the gitdir is separate. >>> The first time I have copied one module to an USB key I had a big >>> surprise. >> >> Oops! Could you please help us by hinting how the documentation >> could be improved here? >> > > Of course. > There is nothing in Documentation/git-submodule.txt to inform that submodules > clones are different from regular clones. > I will write and propose a patch for the documentation. > But maybe in a new thread. Thanks! >>> - This will not change anything for people not using it. >> >> I do not agree, as they'll be seeing a new option and might use >> it to "go backward" as Junio explained in his answer. >> >>> - I use an other patch which I plane to send later which enable multiple >>> level of superproject to add a gitlink to the same submodule. >>> And in this case the superproject containing the separate gitdir will be >>> arbitrary and depend on the processing order of the >>> 'git submodule update --recursive' command. >> >> I don't understand that. How is that different from using different >> names (and thus different separate gitdirs) for that duplicated >> submodule? After all, the .git directory is just moved somewhere >> else in the superproject's work tree, and as the name defaults to >> the path of the submodule ... >> > > I think I should give an example. > If I have a hierarchy like this : > > superproject/submodule/subsubmodule > > What I often do is: > > superproject --> submodule --> subsubmodule > | ^ > '-----------------' > > Where '-->' is a gitlink. > > > That mean .gitmodules and index of the superproject contain both submodule and > submodule/subsubmodule. Wow, that shouldn't even work (as everything inside "submodule" shouldn't be part of the superproject but must be contained in the submodule itself). Do the "git submodule" script and other git commands like "git status" work for you in such setups? > And also mean (and that is the point) subsubmodule is a direct 'child' of both > superproject and submodule. Which I think should not be possible. If that works with current Git I suspect we have a bug to fix ... or does your other patch make this work? > In this case where should the separate gitdir of subsubmodule be placed ? > - In superproject/modules/submodule/subsubmodule ? > - In superproject/submodule/modules/subsubmodule ? > - Depending on the 'git submodule update' command order ? > - Or both ? It should be placed in .git/modules/submodule/modules/subsubmodule of the superproject (assuming the subsubmodule is part of the first level submodule). But in your example that would live in .git/modules/submodule/subsubmodule (but as mentioned above, I do not consider this a valid setup because then two repositories would be responsible for the data inside subsubmodule, which will lead to lots of trouble). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html