Do we really need all those git ignore paths for Envio?

[PaulRBerg]

cc @razgraf @gavriliumircea

I couldn't find any information about these git ignore paths in the Envio docs. Why do we use them?

Ignoring so many paths is an error-prone approach because it can lead to git ignoring files that should not be git ignored. When so many files have to be git ignored, it is typically better to target specific directories.

indexers/.gitignore

Lines 51 to 81 in 07b3166

	# Envio
	**/lib/*
	**/benchmarks/
	**/artifacts
	**/logs
	*.exe
	*.obj
	*.out
	*.compile
	*.native
	*.byte
	*.cmo
	*.annot
	*.cmi
	*.cmx
	*.cmt
	*.cmti
	*.cma
	*.a
	*.cmxa
	*.obj
	*~
	*.annot
	*.cmj
	*.bak
	*.mlast
	*.mliast
	.merlin
	.bsb.lock
	*.bs.js

[razgraf]

Probably not, I think we auto-generated most of them.

Ignoring so many paths is an error-prone approach

I'll take the other side of this debate and say it's actually not problematic to ignore extra files since it can act as a safety net - you don't push unwanted or possibly private output by mistake in case you start generating those files as a result of using some new utility.

On the other hand, I'll agree it's a bit verbose to actually have all of them there.

[PaulRBerg]

Alright. Will open an issue.

If we follow the other side of the debate to its logical conclusion, we should add as many extensions and file paths in all of our GitHub repos, just in case.

that's really not a scalable approach and will 100% lead to git ignoring unwanted stuff and coordination issues because team members are unsure why some files are not part of version control

Private stuff should always be put in .env, and we shuold all use a global .gitconfig that ignores .env