Beware of ~/.git !
NicolasRouquette opened this issue · comments
sbt-ghpages is great; however, there's an annoying behavior.
Suppose we have the following:
~/.git-- i.e., the home directory is a GIT project- no
~/.sbt/ghpages - an sbt-ghpages configured project elsewhere, e.g.
/opt/local/stuff/MyProject
Then, in /opt/local/stuff/MyProject, execute sbt ghpagesPushSite
The generated site will be pushed to the remote of ~/.git instead of /opt/local/stuff/MyProject/.git
A workaround is to move all GIT repos in any parent folder of ~/.sbt/ghpages to avoid GIT picking up an ancestor folder's repository.
It would be nice if the GIT commands issued by sbt-ghpages could be made robust against repositories in parent folders.
I think I had to do this for my dotfiles to work around this issue - eed3si9n/dotfiles@54fe427
@eed3si9n If I understand, your workaround involves making ~/.sbt/0.13 a symlink to a folder, say /opt/local/sbt/0.13.
For this issue, I think we'd have to make ~/.sbt a symlink to a folder, e.g., /opt/local/my-sbt so that ~/.sbt/gh-pages will be effectively /opt/local/my-sbt/gh-pages. This would them make any GIT repo cloned in /opt/local/my-sbt/gh-pages/<hash>/<org>/<project>/.git distinct from ~/.git.
I'll give it a shot over the weekend.
That was just my workaround. For the actual fix on sbt-ghpages, would specifying the working directory solve the problem?
$ git --git-dir=~/.sbt/0.13/gh-pages/<hash>/<org>/<project>/.git --work-tree=~/.sbt/0.13/gh-pages/<hash>/<org>/<project> status