Loet Avramson <[email protected]> writes: > According to git-clone man page - running 'git clone --recursive' "...is > equivalent to running 'git submodule update --init --recursive' immediately > after the clone is finished...", though I found a little difference between > the two regarding the submodule's .git file: > > 1. Running 'git clone' and 'git submodule update --init --recursive' > separately will create the .git file in each submodule containing a relative > path to the superproject's .git directory as expected. > > 2. Running 'git clone --recursive' will create the .git file containing an > *absolute* path to the superproject's .git directory. (as it was expected > using git versions 1.7.8 - 1.7.10 as far as I understand) > > Not sure if that's a bug but it got stuff behaving really weird in a specific > usecase on one of our environments. It would be highly appreciated to update > the docs at least.
If the documentation already says "equivalent" and does not say "identical", I am not sure if there is anything to update. In any case, I thought some people are already working to make the result consistently use relative paths (or was it absolute?), so this may soon become a non-issue. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
