exa treats gitignore `/`s literally

[CosmicToast]

Example test:

Take the following repository structure:

.
├── .gitignore
└── a
│  └── x
└── b
   └── x

with the contents of .gitignore being:

a/
/b

exa --tree --git-ignore will show all of the files.
In comparison, fd and rg --files will show no output.

[rpdelaney]

I came here to post this. For bizarre reasons / is considered by gitignore to be the root of the _repository_, not the filesystem.

[tjkirch]

I use a leading "/" quite often to block objects that only appear at the root of a repo, like "/target" for Rust/Cargo projects. I was pretty confused to see exa listing them when --git-ignore is specified.

[Lucretiel]

I came here to post this. For bizarre reasons / is considered by gitignore to be the root of the _repository_, not the filesystem.

Doesn't seem that bizarre; this seems like a reasonable convention to indicate you want to ignore "project_root/target" but not "project_root/src/target"

[CosmicToast]

Since there appears to be some confusion, let's clarify:
This is the gitignore documentation, and should serve as the implementation basis for any gitignore-related functionality.

As per said documentation:

A leading slash matches the beginning of the pathname. For example, "/*.c" matches "cat-file.c" but not "mozilla-sha1/sha1.c".

In terms of being relative to the filesystem, git does not consider the filesystem paths because git has no control over where the checkout happens. If someone has a checkout in /git/x and has /git/x/y in the gitignore, what happens if someone checked the same repository out in ~/x?

Gitignore only makes sense in the scope of git (rather than the larger filesystem) and thus must not consider anything outside of the repository (including in alternative implemetations, such as here).

(requirement keywords as per rfc2119)