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 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. > > - 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. And also mean (and that is the point) subsubmodule is a direct 'child' of both superproject and submodule. 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 ? > > - I have written this for myself and have using it since 2012 and send it in > > the hope it could be useful for someone else even if it is only a few > > people. But if its not the case no problem I will keep using it for myself. > > Thanks.