Hi there, I created a patch which makes ".gitignore" filename configurabe. Preliminary diff is pasted below. My question is: Would something like this be acceptable for inclusion? (providing documentation and test cases will be done too, of course) See "Motivation" part below for additional explanation. Possible downsides: - default filename .gitignore is kept, so there is no issue here, if this new config option is not changed - increased support questions, but I think generally people would not change this setting without having a good reason Motivation: Git is great for tracking code development, but when deploying mentioned code by using git itself, various configuration files must be created additionally, which are normally .gitignored, for various reasons (code portability, sensitive data, etc). There is currently no simple way of tracking changes to those critical configuration files (at least none that I am aware of). One way to approach this would be tracking those changes in separate git repository. It is possible to create this second repo outside of code repository. But this gets messy very fast (you still need to create symlinks in code repository, or sth). It would be splendid if this configuration tracking repository could be created inside code repository, but in a "separate namespace". (I've just found out that "namespaces" word is already used for different concept in git 2.1.x, so let's call it "dirspace" in this discussion). Separate dirspace is currently possible for ".git" directory via GIT_DIR environment variable. Adding possibility of using differently-named .gitignore files is first step for dirspaces, .gitmodules and .gitattributes are another two filenames that would need to be made configurable. I can imagine a tiny tool, let's call it "gitsth". When called, sets GIT_DIR from .git to .gitsth, and in .gitsth/config configures alternate filenames for .gitignore, .gitmodules and .gitattributes to .gitignoreSTH, .gitmodulesSTH and .gitattrSTH (for example). This .gitignoreSTH could then be used to ignore all files except configuration files that need to be tracked. That is just my imaginative usecase. Think of it as sort of overlay-git. Git would only need to provide tools for it, so that on top of those tools new solutions could be created. Other usecases would probably pop up sooner or later. Thank you for your opinion, b. Readable diff format: http://pastiebin.com/53ff8747b97f1 Actual patch: (redacted, as vger swallowed two sending tries with a "250 2.7.1 Looks like Linux source DIFF email.." response) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html