Add -vcs_ignore flag via libgit2

[losnappas]

Fixes #42

This is entirely vibe coded, I don't really know C that well. It seemed to work, I didn't benchmark it (not really relevant for my use cases), I doubt this:

it should be an on/off thing regardless of where it appears on the command line.

is working. I'm posting this in hopes that someone takes it the rest of the way. Or, with guidance, I can do that too but I'm not gonna be guessing blindly here.

[tavianator]

Left some comments but there is a major design flaw with the current implementation. To work properly it needs to support multiple active repos simultaneously. If you want I can sketch out the ideas I had for that but it would be a major refactor.

[tavianator]

Suggested change

	git_libgit2_init();
	return 0;
	return git_libgit2_init();

[tavianator]

Should be sorted alphabetically

[tavianator]

Should be sorted alphabetically

[tavianator]

Should be sorted alphabetically

[tavianator]

bfs coding style is to use #if for these, not #ifdef, so that #define BFS_WITH_LIBGIT2 false works as expected

Suggested change

	#ifdef BFS_WITH_LIBGIT2
	#include <git2.h>
	#endif
	#if BFS_WITH_LIBGIT2
	# include <git2.h>
	#endif

[tavianator]

This is the wrong place to store this. There is only one bfs_ctx, but there can be multiple git repos active at a time. Consider

$ bfs src/repo1 src/repo2

or even just bfs src/repo in the presence of git submodules.

[tavianator]

Suggested change

	* Parse -ignore-vcs.
	* Parse -ignore_vcs.

[tavianator]

Don't think you need this, it's already set to false in bfs_ctx_new()

[tavianator]

You don't need to do this, just do

invoke_bfs -quit -ignore_vcs || skip

at the top

[losnappas]

Thanks for the review.

Left some comments but there is a major design flaw with the current implementation. To work properly it needs to support multiple active repos simultaneously. If you want I can sketch out the ideas I had for that but it would be a major refactor.

Is your idea still using libgit2? Like checking for repo in each dir?

The way I use this tool, I don't care about nested repos, but I understand it's not as expected.

Also, is the whole #if BFS_WITH_LIBGIT2 needed/wanted, or can we just assume it exists?

[tavianator]

Thanks for the review.

Left some comments but there is a major design flaw with the current implementation. To work properly it needs to support multiple active repos simultaneously. If you want I can sketch out the ideas I had for that but it would be a major refactor.

Is your idea still using libgit2? Like checking for repo in each dir?

libgit2 is fine. I was originally going to write my own .gitignore parser because I thought libgit2's license wasn't compatible with bfs, but actually it seems okay.

The hard part is to find somewhere to store the struct git_repository for every active path. Right now there are a couple different representations of active paths:

• struct bftw_file is private to bftw.c. There is a separate one for each path component, with parent pointers.
• struct BFTW is public, but there's only one alive at a time.

My idea is to unify these into something like struct bfs_path. This new type would chain like bftw_file, making it easy to hang extra data off each path component. So if you're at path/to/repo/sub/dir, you could grab the repo like path->parent->parent->repo.

The way I use this tool, I don't care about nested repos, but I understand it's not as expected.

I want bfs to work pretty much exactly like fd does regarding .gitignore support. If I merge an incomplete implementation that only supports one active repo, improving it in the future becomes a backwards-incompatible behaviour change. I try very hard to minimize those.

Also, is the whole #if BFS_WITH_LIBGIT2 needed/wanted, or can we just assume it exists?

Yes it's needed, all of bfs's dependencies are optional.