Re: Pro Git book: concerning data lost due to ".gitignore"

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

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@gmail.com/
2. https://lore.kernel.org/git/20181209104419.12639-1-pclouds@gmail.com/