Beware of ~/.git !

[NicolasRouquette]

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.

[eed3si9n]

I think I had to do this for my dotfiles to work around this issue - https://github.com/eed3si9n/dotfiles/commit/54fe427e41b3ccd0c0b431db577614bd3fd53b48

[NicolasRouquette]

@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.

[eed3si9n]

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

[NicolasRouquette]

I'd love a fix; however, wouldn't GitRunner need some enhancement to specify these options and then another enhancement to ghpages to specify them?