Linter for files in gitignore

[M-Zuber]

This was first raised in #39
The idea is to add a gitignore field to the language object that will contain the files that are supposed to be not pushed to the repo due the fact that are in the .gitignore file

{
 name: 'language name',
 files: {
 ...
 },
 gitignore: {
 ...
 }
}

Then there would be a separate linter to perform the checks

[basicallydan]

My comment on this from #39

@M-Zuber wrote
What is coming to my mind is adding an object to each language object so that they look like this:
example - see #41

Yes, just like that!

@matiassingers wrote
It's also weird to suggest that some files are required in a .gitignore, like .DS_Store should be in a persons global list instead of the local .gitignore.

Good point. However, as @jonfinerty pointed out offline:

The .gitignore isn't just for the project owner, it's to prevent people who clone it from accidentally uploading ignored files.

So e.g., you have .DS_Store ignored globally, so you don't put it in your .gitignore, and then someone without it ignored globally clones your repo, makes a fork and tries to commit .DS_Store because the .gitignore doesn't exclude it. See what I mean?

So to summarise, I think a global list of files to be expected in .gitignore makes sense, as well as some language-specific ones which are linted in a similar way to how we currently lint language-specific files, e.g. in NodeJS.

In the end, the role of the lintFiles step is there to ensure that files we don't want don't exist, and that required files do exist, and the lintIgnore step is there to ensure that new collaborators don't accidentally commit files that should be ignored, because .gitignore will prevent that.

[M-Zuber]

Here is a list of .gitignore templates

[basicallydan]

@M-Zuber Thanks! Quite a lot to get through!

[M-Zuber]

It can also serve as a checklist of sorts for languages to support 😉

[basicallydan]

Hahah, true yeah!

[M-Zuber]

I merged #51.

Is that what we want and this is done, or do we want to upgrade it to download and parse the .gitignore in the project?

Thoughts on that:

• Part of the defaults is making sure that the .gitignore exists in the first place.
• Is there such a thing as having multiple .gitignore files in one repo?

[basicallydan]

Ooh. That would be good, but would it break the web interface? Argh. Hmm. The web interface is pretty cool, I love the fact that it works in the browser or on the command line. Does GitHub possibly give access to .gitignore files through CORS JavaScript requests?

[M-Zuber]

I'll look into the api, and test it out. Definitely agree that we can't break the web

[basicallydan]

Cool! Let me know when you get to it, if I get some time sooner then I'll do it :)

[M-Zuber]

CORS resource sharing
Downloading a file
These look like the main resources that need to be investigated. In addition I sent an email to a GitHubber I've interacted with in the past to get feedback on the concept of downloading the .gitignore

I am starting to think that it does not make sense. What I might do is try and create a tool that will

• for each language we currently support
  • get .gitignore template using this api
  • somehow convert the values into key/value + regex the value in the language files

Or do it manually ;)
What say you?

[basicallydan]

I like the idea of using the GitHub API to get the gitignore templates because it helps us to suggest what people probably shouldn't have in the repo. But this may change quite a bit for every project, so it may not be such a popular idea.

Worth a try, though, I think. We can always have a "don't use gitignore" flag. We'd have to use pretty much the exact same algorithm as git to make this work though, right?

[M-Zuber]

Your first point is something that I have been trying to come up with a good solution for.
One possibility is (in the not so near future) to update the web interface - not sure how to deal with the CLI - to have a picker for the ruleset, where the user can choose exactly what they want.
Because, the same way not every project follows the .gitignore template exactly - they may also not want to be held to some of the other rules we have.
TL;DR All our rules are subjective, and this particular check is the most invasive - so making it optional is probably the best way to go.

[M-Zuber]

As far as the algorithm goes, I am not sure.
Is the algorithm used by git available?