Create Atom.gitignore #974

wants to merge 1 commit into

4 participants


Wondering if we should put these meta-dotfiles (dotfiles for your settings [dotfile] directories) in a special directory in this repo, e.g. Meta/Atom.gitignore? I have some other examples in my personal dotfiles repo:

/cc @github/atom


People have suggested a dotfiles template before and we initially decided against it in #565, but I hadn't really considered the solution of a new family of templates for this case, which seems a lot nicer to me than the other solutions discussed. Only problem then would be would the maintenance effort and PR influx be worth it for the use-case?

I sort of feel that a dotfiles framework like those mentioned in is still the better solution. After all, the primary purpose of this repo is to populate the gitignore dropdown when creating a new repo (although that list is considerably out of sync with these templates at the moment...).


would the maintenance effort and PR influx be worth it for the use-case?

I think so.

a dotfiles framework like those mentioned in is still the better solution

I don't think it's really different for project .gitignores vs. app-specific ones... couldn't one of those frameworks pull from this repo though? The extension of that argument is that this repository shouldn't exist 😉


What I meant was that pretty much everyone using git needs gitignores for their projects, so the templates here are useful in addition to their purpose on The Global/* templates are broadly useful app-specific ignores even without serving any specific function for

However a dotfiles template or family of templates would only be useful to those people who choose to create a git repo in their home directory. It would take a fair bit of work to curate this new type of templates, and would only benefit some smallish fraction of users. Also as I said, I think dotfiles frameworks handle this problem much better than plain git - they can do things like per-host configuration, setup hooks and selective importing of dotfiles.

While dotfiles frameworks could hypothetically pull from this repo, any of them which know things about specific apps' config files already have their own data. They would have to be convinced to use our data instead, which would entail coupling control of the supported apps (and development speed) to this repo. I can't see that there would be much interest, and without that there seems to be little to achieve by heading in this direction.


I hear you, I just don't think it's a dangerous rabbit-hole by any means. Anyone else have thoughts one way or the other?

GitHub member

From a practical point of view, I don't think we'd do a good job of handling the additional work involved in maintaining another set of gitignore files for dotfiles in this repo. It's already hard to keep up with the number of PRs that come through, and presumably that would only get worse if we started keeping track of another class of gitignore files.

If there are other people that want to step up and maintain the dotfile gitignores, that changes the equation a bit, though it still leaves the question of whether this repo is the right place for them. I'm not convinced yet.


Side question: should .node-gyp/ be ignored as well?

GitHub member

Atom will create a .gitignore file in ~/.atom now via atom/atom@69821b7.


Sahweeeet :metal:

@afeld afeld closed this Apr 30, 2014
@afeld afeld deleted the atom branch Apr 30, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment