Torsten Bögershausen <tboegi@xxxxxx> writes: > Since you ask for a new config option: This needs to be applied > to each and every workstation in use. How could this be done ? > And if it is done from a central IT department, the there > may be a way to configure git hooks on the work station. Unfortunately, I think it is way too naïve an approach to help you all that much to merely stop you from committing anything before you have a .gitignore file, because presence of .gitignore is no sign that you are maintaining a good set of exclusion rules. Recently in one of my toy projects, where .txt files are build products (hence I have "*.txt" excluded), I started tracking one externally-provided tool that is used by the build procedure of the project, but the tool comes its own "*.txt" template files, which means "git add NewToolDirectory/" left out half the files that come with the tool and are essential for the correct operation of that tool. Disaster recovery and history rewriting ensued, but the damage fortunately was small, as I caught it fairly soon before piling many commits on top. Instead, you would want to catch a case where "git add" used to add _new_ files with a rather wide pathspec (e.g., in my case, I named a single directory and meant to add all the "relevant" files to the project---the problem was that the definition of "relevant" is vastly different from the contents that were tracked in the project historically and what was in the new directory) and ended up ignoring many files that _would_ have matched the pathspec and somehow flag it as a potential problem to the user. Thanks.
