Automatically Add .gitignore Files

I frequently forget to add .gitignore files when creating new .gitignore files.

I'd like to request a command-line option to always add .gitignore files (or, more generally, always add files that match a given file specification).

Replicate

0. git init ...
1. echo "*.bak" >> .gitignore
2. touch file.txt
3. git add file.txt
4. git commit -a -m "..."
5. git push origin master

Expected Results

The .gitignore file is also added to the repository. (This is probably the 80% use case.)

Actual Results

The .gitignore file is not added to the repository.

Additional Details

At step 4, there should be a prompt, warning, or (preferably) either a command-line or configuration option to add the .gitignore file prior to commit, automatically. Such as:

git commit --include-all-gitignore-files -a -m "..."

Or:

echo "**/.gitignore" >> .git/config/add-before-commit

Thangalin <thangalin@gmail.com> writes:

That is essentially what "Untracked files" listing in the editor buffer given to you when you type "git commit" is about. By not saying you ignore .gitattributes, .gitignore, .gitmodules, etc., you are reminded if you forgot to add them. "git status" does the same, and perhaps you want to make it a habit to run it before committing.

I am tempted to say that there should be a way to somehow forbid use of the "-m" option to "git commit" by default, until the user gains more familiarity with use of Git. That way, they will learn to pay more attention to the "Untracked" and "Changes not staged" sections ;-)

Since I am using git, I am tempted to say that "git commit -m" should be abolished. If I tell somebody how to use git, I never mention "git commit -m". Unluckily they find it out themselves... ;D

The typical observations I have when people use "git commit -m":

 * The commit messages are either too long (in one line!) or
   too meaningless.

 * People don't check what they added and commit wrong stuff.

 * People make fast temporary commits with "asdafsd" commit messages.
   Then they get distracted for some time and work on another branch.
   When they turn back to the old branch they don't know what "asdafsd"
   was...

Thanks to git rebase -i and/or git commit --amend, it is all not too bad after all ;D

Best
  Stephan

On Thu, Feb 9, 2017 at 2:05 AM, Thangalin <thangalin@gmail.com> wrote:

This is a general problem to new files, not .gitignore alone. Can we accomplish something with some hook? At the least I think we should be able to detect that .gitignore is not detected and abort, prompting the user to add it. It's easier to customize too, and we don't have to cook ".gitignore" in the code.

I'm not sure if we tell the hook "this is with -m option" though..

Hi Duy,

The difference, to me, is that a ".gitignore" file is not part of what I'm developing. It's an artifact for git configuration. While a .gitignore file is not always pushed to the repository, I imagine that in most situations, it is.

Whereas when a "new" file is created, there are plenty of situations where it shouldn't be added and thus a warning would be superfluous, or an automatic add would be undesirable.

To solve the problem, generally, for new files while giving the user the ability to specify exactly what "new" files should be automatically added to the repository, something like the following would work:

echo "**/.gitignore" >> .git/config/add-before-commit

Right, because software shouldn't automate repetitive tasks and humans are never prone to forget? ;-)