Stack moving Git clones under .stack/downloads/ from their .tmp names causes build problems

[da-x]

The following issue happens with Version 1.1.0, Git revision 752100285335b2f18a3fec0039bd0581e8c25468 (3546 commits) x86_64 hpack-0.13.0 using Git 2.8.1.

When trying to build Lamdu which has a stack.yaml having a Git dependency over another package that has a submodule, I got the following:

--  While building package bindings-freetype-gl-0.1.0.0 using:
      /home/dan/dev/gh/da-x/lamdu/.stack-work/downloaded/22e1318b53013f3cd452538c0584632668207c3d460c75655f8c68a588e92f4b/.stack-work/dist/x86_64-linux/Cabal-1.22.5.0/setup/setup --builddir=.stack-work/dist/x86_64-linux/Cabal-1.22.5.0 build lib:bindings-freetype-gl --ghc-options " -ddump-hi -ddump-to-file"
    Process exited with code: ExitFailure 1
    Logs have been written to: /home/dan/dev/gh/da-x/lamdu/.stack-work/logs/bindings-freetype-gl-0.1.0.0.log

    Configuring bindings-freetype-gl-0.1.0.0...
    fatal: Not a git repository: /home/dan/dev/gh/da-x/lamdu/.stack-work/downloaded/22e1318b53013f3cd452538c0584632668207c3d460c75655f8c68a588e92f4b.tmp/.git/modules/freetype-gl
    Unable to find current revision in submodule path 'freetype-gl'

Looking into this, I've discovered that Stack clones the Git repo to the path of 22e1318b53013f3cd452538c0584632668207c3d460c75655f8c68a588e92f4b.tmp, and then moves it to 22e1318b53013f3cd452538c0584632668207c3d460c75655f8c68a588e92f4b, i.e. removing the .tmp. However, the problem is that under the clone, the .git files pointing to the submodule repo contain absolute paths - the ones that existed used when the repo was originally cloned - with the .tmp name.

I fixed it manually by finding the submodules. The following lists both the clones and their submodules:

$ find .stack-work -name .git  
.stack-work/downloaded/ef8b900fd7251ea7083f1dee22b0779ce4c02abea73da75c292f7ede4d81d508/.git
.stack-work/downloaded/a78089d81a0c6071df51d106f4ba859febe7d917ffa1748173baf50d22c6e41e/.git
.stack-work/downloaded/22e1318b53013f3cd452538c0584632668207c3d460c75655f8c68a588e92f4b/.git
.stack-work/downloaded/22e1318b53013f3cd452538c0584632668207c3d460c75655f8c68a588e92f4b/freetype-gl/.git
.stack-work/downloaded/107a5d576e4b2460c6da863588cc372792fe085acceb4caa722cc3462f4f63a8/.git
.stack-work/downloaded/09c599f36088ecfad3a4c2f2c8fbb6ab98d2c92ec9a78e191547905a73aca033/.git
.stack-work/downloaded/e7407878fefbd2ce514d6e1b14f42d130e5c3b493ab477dc845ea6f0e32a6682/.git
.stack-work/downloaded/e7407878fefbd2ce514d6e1b14f42d130e5c3b493ab477dc845ea6f0e32a6682/node/deps/v8/.git
.stack-work/downloaded/e7407878fefbd2ce514d6e1b14f42d130e5c3b493ab477dc845ea6f0e32a6682/node/.git
.stack-work/downloaded/9903c5481af6983d7f3469a564c24e3a5b89e3a471e319036773c55fe44639a7/.git
.stack-work/downloaded/620ee25d5792caa7d6dfcc035487704719f8a22dea32e495649c75c61773e8de/.git

The problem is here:

$ cat .stack-work/downloaded/22e1318b53013f3cd452538c0584632668207c3d460c75655f8c68a588e92f4b/freetype-gl/.git
gitdir: /home/dan/dev/gh/da-x/lamdu/.stack-work/downloaded/22e1318b53013f3cd452538c0584632668207c3d460c75655f8c68a588e92f4b.tmp/.git/modules/freetype-gl

So I edited the 3 submodules shown above, and got around it temporarily.

I guess that the fix would be to mind the submodules somehow. Maybe not move the clone, or by fixing the paths in the .git files after moving them? Or, perhaps consulting with the authors of Git in order to figure out how to freely move Git clones around. I wonder why they decided to use absolute paths? Maybe there's a way to run the clone command in a way that does not generate these absolute paths.

Just trying it outside of Stack:

$ mkdir ~/some-git-clone-test
$ cd  ~/some-git-clone-test
$ git clone --recurse https://github.com/lamdu/bindings-freetype-gl
$ cat bindings-freetype-gl/freetype-gl/.git
gitdir: /home/dan/some-git-clone-test/bindings-freetype-gl/.git/modules/freetype-gl

Looks like it's default behavior for now :(. Saw nothing in the man page for it. Can dig into the Git repo of Git but I have other things to do.

[mgsloan]

Good point! Fixed on master along with #1620 . Please let me know if it doesn't work.