Fwd: Add git ignore as builtin

After seeing -e option in git config (open config files in editor)

http://git-scm.com/docs/git-config

I decide it's time to propose to incorporate an alias really useful to me

git ignore

The repo is on https://github.com/albfan/git-ignore

basically:

git ignore <whatever> adds <whatever> to .git/info/exclude

and git ignore -e starts an editor to tweak your excludes

by default it operates con exclude file, but it can also work with .gitignore using -i option

I find it invaluable for IDE project files, TODOs, test files...

Alberto Fanjul Alonso <albertofanjul <at> gmail.com> writes:

This should be "git exclude" not "git ignore". Difference between the two: http://stackoverflow.com/questions/10066749/git- excludes-vs-ignores

I'd second the notion of a "git ignore", however it would have to modify the `.gitignore` not `.git/info/exclude`.

On Mon, Nov 17, 2014 at 12:12:25AM +0000, Ryan Jacobs wrote:

I am not sure that the name difference is all that meaningful. Yes, we call the repo-wide file .git/info/exclude and the in-tree ones .gitignore, but I do not know if the distinction is more than historical accident.

And I think this is a good reason why we do not have a "git ignore" tool to write such things. If I say "git ignore foo" should it go into .git/info/exclude or .gitignore? If the latter, should it be "foo" to match everywhere, or "/foo" to match only the single path at the root? If the file is "subdir/foo", should it go as "/subdir/foo" into the top-level ".gitignore", or as "foo" into "subdir/.gitignore"? If you ignore "foo.o" and "bar.o", should we suggest that you ignore "*.o" instead?

Trying to accomodate all of those possibilities in a command-line tool is hard, and probably counter-productive. We already have a simple domain-specific language for specifying .gitignore files. You can just try to cover a common case, like "always put the full slash-prefixed path into the top-level .gitignore". But then I wonder if "git ignore" is really adding much value, as it is just a thin wrapper around "echo".

-Peff

PS The more interesting case to automate (to me, anyway) is _checking_
   paths against the hand-written .gitignore rules, which is complicated
   to do by hand.  You can do that already with "git check-ignore".

Jeff King <peff@peff.net> writes:

It is merely a historical accident.

I would love to have such tool included in the toolchain, but being able to use it to edit all the ignore chain, defaulting to .gitignore. Explain the reason in my case.

Usually, when ignoring stuff, you will probable ignore already your IDE/Editor files using a global gitignore. And most of the times in a per-project basis, you will be ignoring their output files. I only use .git/info/exclude when I have something really special that I don't want to share publicly, such as a data/ folder to run the project or so.

That way, most of the times I will be modifying .gitignore, sometimes my global gitignore and very occasionally, .git/info/exclude.

That's my case, and that I know of, people have that usage order, .gitignore > global gitignore > local gitignore.

For sake of uniformity, I would use the same context specifiers as in git-config. Defaulting to --repo for .gitignore, using --local for the .git/info/exclue, using --global for the global gitignore, and --system for the system one.

Also, about adding and excluding, I would recommend using verbs instead of arguments, which would be in consonance with git remote.

git ignore exclude .... git ignore include ....

You could also make it "smart" by allowing to use it as the Cisco managing commands, or the ip tool (ip a == ip address, ip a a == ip addr add, etc.), resulting in the following: git ignore e .... git ignore i ....