Respect gitignore rules in git repositories, ala ripgrep

[anrddh]

Thanks so much for creating gemini!

It works great, except it tries to format and prints warnings about 3rd-party CMake files pulled into my build tree (which is a sub directory of my source tree) by vcpkg when I run it like gemini -i --definitions stuff... -- ..

I'd also be happy to have a crack at making a PR for this myself.

[BlankSpruce]

Hello there. Gemini? You're in the wrong neighbourhood. 😆

I really love ripgrep and I understand the temptation to follow the similar behaviour. However I think that both tools are used in different circumstances, with different frequency and different usage pattern. You'll usually use ripgrep tens or hundreds of times daily:

• with different inputs,
• with different flags (like -A5 -B3)
• in various working directiories.

It absolutely makes sense to make it as convenient as possible. However not all grep-like tools support that, notable exception being ack: https://beyondgrep.com/feature-comparison/

On the other hand (to my knowledge) formatter is used typically like so:

• once when formatter is introduced in the project
• on single file when your editor uses some hook to update formatting before save
• before commiting to update formatting of whole batch of changed files

I rather don't intend to support ignoring files in any way because user can always provide much more precise ignoring themself. Also even if I was somewhat convinced that it's worth the time then I'd like to support popular version control systems equally, to avoid taking favourites. This would lead me to finding library that parses those ignore files correctly and that thing I'd also like to avoid. Fewer dependencies the better. Just recently I got rid of dependency because it became problematic in some environments.

All that being said I won't leave you without a hint. Or a couple of hints actually. I'll go through 4 known to me solutions to your problem, each with its own caveats:

1. Don't place build directory in your repository. Seriously. From my experience it attracts more problems than it solves. Of course I'm not ignorant that sometimes this is inevitable "because reasons" and you're stuck with current approach. In that case...
2. Use pre-commit with this hook definition. Files tracked by git repository will be correctly passed to the formatter. As an additional benefit you can invite others to install such hook so that consistent formatting is used consistently™ by everybody. Of course you might have a reason to not use pre-commit in your project. In that case...
3. Consider explicitly mentioning files and directories that you want to be affected by formatter. Usually you'll have to mention just single top-level CMakeLists.txt and all the interesting subdirectories because gersemi will find files in the subdirectories. Here's an example based on obs-studio project how it would look like:

   # I've intentionally omitted "deps", "docs" 
   # and used "libobs-*" glob pattern so that underlying shell will help me in that regard
   gersemi -i --definitions cmake -- CMakeLists.txt UI cmake shared plugins test libobs-* 

   Now you might say "But this is error-prone, what if directory structure changes and something won't be formatted?". In that case...
4. Kudos to expipiplus1 who showed me this approach in this script in regard to avoiding formatting of submodules. You can leverage git to ignore files that are intended to be ignored. Who understands .gitignore better than git itself? Here's how you would do that in most succinct form:

   gersemi -i --definitions cmake -- $(git ls-files "*.cmake" "CMakeLists.txt" "**/CMakeLists.txt")

Before we go with pull requests let's weigh pros and cons of supporting that feature. I assume no ill will but whatever extra feature is added to the project it might become my maintenance burden. Since I'm quite lazy person I will avoid that as long as reasonable. :)

[anrddh]

Sorry about the typo :P

I empathize with your general desire to minimize features and dependencies. Your outlined workarounds are solid. Thanks for the detailed response!

[BlankSpruce]

I've pinned this issue for reference so that alternatives are easily accessible. In case I stumble upon new alternative I'll post it here.