On 09/15/2014 05:58 PM, Dale R. Worley wrote: > $ git clone git://git.sv.gnu.org/findutils > Cloning into 'findutils'... > remote: Counting objects: 18835, done. > remote: Compressing objects: 100% (3464/3464), done. > remote: Total 18835 (delta 14976), reused 18835 (delta 14976) > Receiving objects: 100% (18835/18835), 9.33 MiB | 1.25 MiB/s, done. > Resolving deltas: 100% (14976/14976), done. > $ cd findutils > $ sh import-gnulib.sh > Checking the submodule directory layout... > You have a ./gnulib directory which does not appear to be a submodule. > > Findutils now manages the gnulib source code as a git submodule. > > If you are still using the directory layout in which the git tree for > gnulib lives in ./gnulib-git/, please fix this and re-run > import-gnulib.sh. > The fix is very simple; please delete both ./gnulib/ and ./gnulib-git. > > This wasn't done automatically for you just in case you had any local > changes. > $ > > Now I thought that Git couldn't represent a directory containing no > files, but the error message is correct, the "gnulib" directory exists > and is empty after the git-clone. > > So something needs to be fixed here, either the structure of the Git > file tree, or the code in import-gnulib.sh.
Thanks for the report. import-gnulib.sh is quite old, and we're recently discussing to replace it with the current 'bootstrap' script from the upstream gnulib project. Unfortunately, I didn't have enough time to get this to work yet. So for your case, I recommend to do what the above output already suggested: remove the gnulib directory and start over with import-gnulib.sh. Have a nice day, Berny
