`neocities push .` incorrectly applying .gitignore rules.

[MesropM]

neocities push . will attempt to push files that should be ignored as per the .gitignore file.

I am on a mac and so I have .DS_Store in my .gitignore. Pushing ignores the .DS_Store file in the directory I run it from, but will attempt to push any .DS_Store files it finds in other directories.

For example, I have a folder called fonts, and this has a .DS_Store file in side of it. When attempting to push, neocities will ignore the .DS_Store file in the directory its run from (as expected from the .gitignore), but will attempt to push (and fail to do so) when it finds the .DS_Store file in the fonts directory.

If I try to specify fonts/.DS_Store in my .gitignore file, neocities will successfully ignore the file, but I will have to do this for every directory. It seems that the push command does not check for ignored files in every directory, only the directory it's run from.

It was working as expected, but when I updated to the latest version 0.0.18, this issue began (I do not know which version I updated from).

[vadcx]

git check-ignore can be used in a streaming fashion to check any path for ignore rules with only one process invocation:

Command: git check-ignore --no-index --stdin -v
STDIN: here.mysecret <Press Enter or Enter+CTRL-D to end>
STDOUT (after sending the line): .gitignore:1:**.mysecret  here.mysecret

.gitignore:

**.mysecret

This works correctly with any complexity of git's ignore rules and will pick up the repository even if it's in a parent folder. It only DOES NOT ignore the own .git folder by default. Git must have a special handling of its own folder.

The fix should be a relatively simple CLI interaction between neocities and git (#47). The current approach is broken or outright unsafe for possibly leaking secrets. Link to current code I'd have done it if I had any idea of ruby.

[gllghr]

I agree that relying on an existing git implementation to apply the .gitignore rules would be more robust.

I have a working prototype of a fix for this and a few related issues: gllghr@928b92d

However, that change adds a dependency on rugged, which is a wrapper for libgit2. rugged is nice in that it ships with libgit2, so you don't need to worry about finding or not finding the git executable at runtime. The downside, though, is that it gets compiled when the gem is installed, so end users have to have the libgit2's build dependencies installed, including make, cmake, and pkg-config. It's not too bad on Linux, but from what I've read it might be painful on Windows (not sure about macOS). Unless someone knows of an easy way to ship a precompiled version of libgit2 with the gem, I think rugged might be a no-go.

So I guess I might just shell out to the git executable. The main issue there is correctly handling cases where git isn't installed or isn't on the path. If we are actually pushing a git repo, or a subdirectory of a git repo, its seems fine to just print an error saying "install git and make sure it's on the path or else use --no-gitignore." On the other hand, if git isn't installed and it isn't a git repo, I don't think it would be great to throw an error. Sure, the user could just pass --no-gitignore, but it seems pretty sub-optimal for someone who isn't using git to get an error and have to figure out why. To avoid printing the unnecessary error, we'd need to know whether we are in a git repo or not, without using git. We'd need some logic which walks up the directory tree and looks for a repo (a .git/ directory with the right contents). There are a few edge cases, but overall the required logic doesn't seem too bad.

[vadcx]

To avoid printing the unnecessary error, we'd need to know whether we are in a git repo or not, without using git.

I think a simple courtesy check up and down the directory tree should be enough. Only for the users who somehow wanted to rely on git, but don't have it installed yet. This intersection of user groups should be extremely small: either you want git and have it already installed or the user doesn't know there's a program called "git". The default shouldn't bother the latter.

git > libgit2 in terms of popularity? I have it on my Manjaro install, but don't see what package depend(ed) on it. The wrapper is nice, but would probably increase the size of the user group in the previous paragraph, when they have git, but not libgit2 installed. In that case, I'd suggest to force an explicit --no-gitignore when git is found, but you decide to implement only rugged/libgit2 for this feature.

Hopefully Kyle is interested...