fix: ignore .gitignore files that are directories

[Byron]

This happens in real-life, and Git itself doesn't budge.

Related to gitbutlerapp/gitbutler#3876

[Skgland]

This function here appears to be under #[cfg(not(windows))] making cfg!(windows) always false.
The #[cfg(windows)] below should probably be changed instead.

[Byron]

That's a great catch, thank you!

I pushed the fix into this standing PR.

[EliahKagan]

Should something be done so that new binary installations of gitoxide (i.e., pre-built gix and ein binaries) use the new dependencies?

When installed from source using cargo install gitoxide, or with cargo install --path . from a clone of the gitoxide repository, commands like gix status no longer fail due to the presence of a .gitignore directory. They behave as expected, no longer being tripped up by a the presence of such a directory:

% git ls-files
.gitignore/a
% gix status
 12:07:41 status done 1.0 files in 0.01s (183.0 files/s)

head -> index isn't implemented yet
% echo "$?"
0

But when installing with cargo quickinstall gitoxide or cargo binstall gitoxide, this still happens:

% git ls-files
.gitignore/a
% gix status
Error: Failed to update the excludes stack to see if a path is excluded
% echo "$?"
1

In both cases, this is with gitoxide 0.36.0.

It may be that nothing should be done. If the main affected subcommand is status, then the behavior of gix could perhaps wait until #1368 is done and merged, anyway. On the other hand, gix commands having two different behaviors even at the same version of gitoxide installed, due to non-intended differences in dependency versions, could be confusing. Then again, directories named .gitignore are uncommon. I'm not sure.

[Byron]

Thanks for making me aware of this.

I think the only way to assure such updates become available in cargo quickinstall is to create a dummy gitoxide patch release to incorporate them and I think for important (i.e. security related) fixes this should certainly be done one way or another.

For this one, I think it's OK to leave it as is and do nothing.

[NobodyXu]

I think the only way to assure such updates become available in cargo quickinstall is to create a dummy gitoxide patch release to incorporate them

I could delete the cargo-quickinstall release for gitoxide, that should trigger a rebuild later.

[Byron]

If you would like to practice this workflow on that occasion, I'd take you upon that offer. Maybe one day that will come in handy for emergency fixes of sorts.
Thanks again!

[NobodyXu]

Removed gitoxide from cargo-quickinstall, waiting for it to rebuild.

[EliahKagan]

This happens in real-life, and Git itself doesn't budge.

While git permits this on all systems, on Windows it gives a warning that creates the appearance that it does not. I've opened git-for-windows/git#5068 for this.