Git version resolution for path-based dependency

[llucenic]

It is fairly legal in case of a git submodule that .git is a regular file. Git accepts this file in its --git-dir parameter in git describe. Thus rendering the isDir() check in determineVersionWithGIT(NativePath path) being counter-effective.

This PR partially fixes #1303.

[dlang-bot]

Thanks for your pull request and interest in making D better, @llucenic! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

• My PR is fully covered with tests (you can see the annotated coverage diff directly on GitHub with CodeCov's browser extension
• My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
• I have provided a detailed rationale explaining my changes
• New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

---

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

[llucenic]

Please help me with the interpreting of failing checks. I do not understand what should be changed in order to pass them.

[wilzbach]

Don't worry about Jenkins it used to be very unstable in the last few months thought this got better over the last weeks as we started to look into the failures more carefully.
AppVeyor is just a download failure.

Anyhow, I'm sorry that this got lost in the queue.
I see your point for removing the check, but it would be much stronger if your PR would be accompanied by a unittest for it. This would greatly help to prevent regressions in this matter ;-)

[wilzbach]

This is harmless change anyhow - even if git_dir doesn't exist, the method will still return null and with verbose logging an error message. Though of course there's the penalty of invoking git

[llucenic]

I will write a unit test, but frankly I have no idea how it should look like in a change like this :-)

[wilzbach]

but frankly I have no idea how it should look like in a change like this :-)

Have a look at e.g. https://github.com/dlang/dub/blob/master/test/4-describe-data-1-list.sh

Essentially you create a the layout that's needed to reproduce this in test (like e.g. https://github.com/dlang/dub/blob/master/test/describe-dependency-2/dub.json) and then add a test as bash script.
I think it's best to do this from master, s.t. your bash script fails with master and once it does you switch to your branch and it should pass.
For git submodules, I think the easiest is to create them in a temporary directory that's nuked with a bash trap (I'm not sure whether all CI scripts do a --recursive clone atm).
Otherwise there's also e.g. https://github.com/dlang-community/gitcompatibledubpackage