Re: .gitignore, .gitattributes, .gitmodules, .gitprecious?, .gitacls? etc.

Dmitry Kakurin <dmitry.kakurin@gmail.com> writes:

Merging what has traditionally been known as .gitignore's capability to attributes has been discussed, and I think it would make sense in longer term, as 'this path pattern is to be ignored' is just a special case of a more general attribute. And "precious" handling would naturally fit there. However, as the .gitignore and .git/info/exclude has been as old as git itself (I think it was introduced around early May 2005), I do not see us even start talking about deprecating .gitignore.

I do not think .gitmodules fits the model of what .gitattributes solves. .gitattributes is about the attribute of paths, while .gitmodules is about attribute of subprojects, and one attribute of a subproject is where in the superproject directory hierarchy it sits at.

I do not know what you are talking about with .gitacls. Personally I am not interested in turning git into a back-up program at all, so if you are talking beyond what has already been suggested as "owner", "group" and "perms" attributes that could be stored in .gitattributes, I do not think it belongs to git.

You are free to _feel_ whatever you want without thinking, but please keep that _feeling_ to yourself, and speak it out after making it into an _opinion_, which would take a bit of thinking about it first. For example, think about what you could do without confusing a total newbie after the initial clone. You cannot avoid chicken-and-egg problem. I think reading from index as a fallback measure when work tree file is missing is a very good compromise we came up recently. The wish of the user (i.e. the owner of the work tree) overrides what is in the index, and the index is how the repository contents are initially propagated back to the work tree.