On Sat, Jun 05 2021, grizlyk wrote: > Good day. Hi. > 1. Summary. > > It should be explicitly warned in the Pro Git book https://git-scm.com/book/en/v2 (and in git man also) that the ".gitignore" feature is very dangerous stuff and should be used with care. This mailing list does not maintain that book. For any issues with it see the issues/PR's at https://github.com/progit/progit2. > Due to ".gitignore" usage, some data files in directory placed under > git version control, can be lost for indexing and can be not placed > into repo _unexpectedly_ for user. I skimmed the rest of your mail, I think you might find the previous discussion(s) about a "precious" attribute at and adding something like a backup log when we shred files due to gitignore[2] interesting and relevant to much of what you point out. I don't think the notion of moving to some general workflow of compiled files being staged elsewhere than the source is something that's viable as a general constraint for a VCS like git. It's way too common of a pattern to e.g. have a *.o file made from a corresponding *.[ch] file(s) in the same directory. For those for whom the solution you suggested works I believe git already does a good job of supporting it. You'd e.g. compile all your assets outside of the repo via your build system, and just not have anything in .gitignore. I don't see how we could expect to smartly deal with having some parallel tool like VS that's (supposedly, I'm just taking your summary at face value) actively working against the wishes of its users. Something like .git/info/exclude is useful, but only assuming that your tooling isn't actively trying to subvert you. 1. https://lore.kernel.org/git/20190216114938.18843-1-pclouds@xxxxxxxxx/ 2. https://lore.kernel.org/git/20181209104419.12639-1-pclouds@xxxxxxxxx/
