Incorrect paths when using nested Danger

[Skoti]

Report

I'm converting my comment from here: #1177
into an issue, as 1177 was closed and no one seem to care.

Assume

.
├── .git
├── nested
│     ├── nested-again
│       ├── Dangerfile

When executing danger from nested-again directory the paths returned by git.renamed_files, git.modified_files and git.added_files are incorrect. They will all start with /nested/nested-again/someFilename instead of just ./someFilename as this is the current working directory.

This leads to issues in all plugins as most of them is doing File.expand_path on the returned paths and the final path is:
/Users/<username>/<path_to_repo>/nested/nestedAgain/nested/nestedAgain/someFilename leading to:
(No such file or directory) errors.

I don't know where is the root cause but it seems like the change to make danger run in a subdirectory is not completed.
Would you please take a look at this?

Example of an issue in swiftlint plugin:
ashfurrow/danger-ruby-swiftlint#175

I've checked this on Danger 9.2.0.

[orta]

Would you please take a look at this?

Danger Ruby is a very mature, done OSS project, I'm afraid folks aren't going to be fixing bugs or adding features for other people, you're welcome to look at this if it is important to you though

[manicmaniac]

Honestly I don't think this is a bug.

git.renamed_files, git.modified_files and git.added_files are internally calls git diff.
I think it is natural that they return files related to top-level of the Git work tree instead of the current directory.

[Skoti]

That's the point.
The #1177 PR was supposed to make it possible to run Danger from a subdirectory.
As I explained in my first post, it seems like it missed the fact that git diff always returns paths relative to the git directory instead of the current directory, hence the common part of the path is added twice.
Seems like the paths should be relativized before expansion.