Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Include other editors than JetBrains in the .gitignore #20

Open
springdo opened this issue Jul 6, 2017 · 19 comments
Open

Include other editors than JetBrains in the .gitignore #20

springdo opened this issue Jul 6, 2017 · 19 comments

Comments

@springdo
Copy link

springdo commented Jul 6, 2017

Hello,

I would like to include some other editors such as Eclipse in the workspace exclude for the .gitignore.
Happy to PR if you feel appropriate

@vpanjganj
Copy link
Collaborator

Yes, please go ahead, thanks.

@bluepeter
Copy link
Contributor

Honestly, the .gitignore is some kinda of crazy... why such an elaborate one? These are things that should be configured on a case by case basis... and really, many of these feel as though they belong in user dir, vs project dir.

@bluepeter
Copy link
Contributor

bluepeter commented Jul 6, 2017

A ~600 line default .gitignore is just asking for trouble... and is going to scare off new users from editing it to tune to constantly changing needs.

@vpanjganj
Copy link
Collaborator

@bluepeter What do you suggest? Maybe we can promote one of these .gitignore generator tools?

@bluepeter
Copy link
Contributor

bluepeter commented Jul 6, 2017

I'm not sure, but this feels honestly counterproductive. Some people will assume this is the "default" and go with it. As a result, they will get something completely counterproductive such as:

### Web ###
  | *.asp
  | *.cer
  | *.csr
  | *.css
  | *.htm
  | *.html
  | *.js
  | *.jsp
  | *.php
  | *.rss
  | *.xhtml

... which I can't ever imagine every being useful?

I'd honestly scrap it. It requires too much configuration. Havent' looked at any of the generators. Perhaps, instead, give some common-sense advice on rationale behind .gitignore strategies... e.g., why they shouldn't check-in node-modules/ etc.

@springdo
Copy link
Author

springdo commented Jul 6, 2017

It is very unweildy at the moment the .gitignore - perhaps the suggestion here is not to include ALL of this as what you'd include in your project but examples for common project types? Or groupings for tech types? It's always handy having a gitignore to hand when starting a new project

@springdo springdo changed the title Include other editors that JetBrains in the .gitignore Include other editors than JetBrains in the .gitignore Jul 6, 2017
@antony
Copy link

antony commented Jul 6, 2017

@bluepeter is right. keep your IDE ignores on your machine. Nobody needs to ignore an enitre IntellIJ IDEA file-based project structure when they use tmux+vim for development.

Best to keep .gitignore focussed on global ignores specific to the project.

@vpanjganj
Copy link
Collaborator

The reason I put editors in there was based on my own experience. I had to delete someone else's .idea folder from repos.

@antony
Copy link

antony commented Jul 6, 2017

@vpanjganj and I absolutely have experienced the same thing - but rather than pollute .gitignore I think this scenario is a good time to educate other collaborators about the ability to have a local set of .gitignores for such things. It comes down to discipline, much like following a set of project guidelines like this :)

@yeskunall
Copy link
Contributor

yeskunall commented Jul 6, 2017

I see the need to ignore .idea and other files and folders generated by IDEs to manage project settings, but what about cases where pushing those configurations is encouraged, for example, in the case of people using vscode? In that case, it makes sense to push .vscode to enhance the developer environment.

A ~600 line default .gitignore is just asking for trouble

I actually agree with @bluepeter on this one. From what I understand, that .gitignore was created by pulling the data from gitignore.io, so I'd like to make a suggestion:

Maybe we can expand on the section for .gitignores. We can start by mentioning that the .gitignore for a specific project varies greatly based on the development environment (editors, IDEs, OS) and the technologies used in that project. (Node, Go, PHP, etcetera) Keeping that in mind, we can break that large .gitignore file into smaller chunks and point to the different .gitignores according to the project needs and requirements.

Thoughts?

@skyrpex
Copy link

skyrpex commented Jul 6, 2017

I would just add rules to the gitignore that are related to the project, not the editor. For example, node_modules and .log files. Other things should be globally ignored by the user.

@vpanjganj
Copy link
Collaborator

in the case of people using vscode?

I think the current config for vscode handles that. You most likely want to push tasks.json etc...

### VisualStudioCode ###
.vscode/*
!.vscode/settings.json
!.vscode/tasks.json
!.vscode/launch.json
!.vscode/extensions.json

A ~600 line default .gitignore is just asking for trouble

I agree with that as well, I think this file should be trimmed down.

Go, PHP, etcetera, Keeping that in mind

I think we stick to be guidelines for JavaScript projects for now and do it right, this also prevents the docs from getting enormous.

My suggestion is:

  • Adding the major Javascript IDEs (how many are they 5? 6?)
  • Adding default OS files that we usually add to .gitignore,
  • node,javascript usuals (node_modules, *.log, etc...)

@vpanjganj
Copy link
Collaborator

@skyrpex

Other things should be globally ignored by the user.

You know what, I think you're right.
In that case we can have a small description on how each developer should set a global .gitignore and then as you said, add the usual ones (node_modules etc...)

@antony
Copy link

antony commented Jul 6, 2017

If I were to create a new project I'd start with an empty .gitignore. I'd then add *.log, and node_modules in the first few commits.

Beyond that my .gitignore files are generally quite empty, for frontend projects I'm likely to add an ignore for a babelified/compiled/thirdparty directory perhaps.

How about rather than massively engineering a very simple file and encouraging blind copy+paste, you simply add the basic javascript defaults, then have a quick summary of how to encourage local ignores, and then guidelines on what things a user might add to the file, and how they might do it.

I think that way it becomes educational, hence a guideline, but also good as a basic seed for building a node project.

@yeskunall
Copy link
Contributor

yeskunall commented Jul 6, 2017 via email

@vpanjganj
Copy link
Collaborator

vpanjganj commented Jul 8, 2017

Hey guys, What do you think of this as a quick fix?:

### Node ###

# Logs
logs
npm-debug.log*
yarn-debug.log*
yarn-error.log*

# Optional npm cache directory
.npm

# Dependency directories
/node_modules
/jspm_packages
/bower_components

# Yarn Integrity file
.yarn-integrity

# Optional eslint cache
.eslintcache

# dotenv environment variables file
.env

#Build generated
dist/
build/


### SublimeText ###
# cache files for sublime text
*.tmlanguage.cache
*.tmPreferences.cache
*.stTheme.cache

# workspace files are user-specific
*.sublime-workspace

# project files should be checked into the repository, unless a significant
# proportion of contributors will probably not be using SublimeText
# *.sublime-project


### VisualStudioCode ###
.vscode/*
!.vscode/settings.json
!.vscode/tasks.json
!.vscode/launch.json
!.vscode/extensions.json

### WebStorm/IntelliJ ###
/.idea
modules.xml
*.ipr


### System Files ###
.DS_Store

# Windows thumbnail cache files
Thumbs.db
ehthumbs.db
ehthumbs_vista.db

# Folder config file
Desktop.ini

# Recycle Bin used on file shares
$RECYCLE.BIN/

# Thumbnails
._*

# Files that might appear in the root of a volume
.DocumentRevisions-V100
.fseventsd
.Spotlight-V100
.TemporaryItems
.Trashes
.VolumeIcon.icns
.com.apple.timemachine.donotpresent

Any thought?

How about rather than massively engineering a very simple file and encouraging blind copy+paste, you simply add the basic javascript defaults, then have a quick summary of how to encourage local ignores

@antony Sounds like a good idea do you think you can come up with something?

@yeskunall
Copy link
Contributor

@vpanjganj looks much, much better than the original .gitignore!

@antony
Copy link

antony commented Jul 9, 2017

@vpanjganj I'll have a go yeah

@MichalZalecki
Copy link
Contributor

New proposal for .gitignore is definitely better but I would switch editors-specific rules for information how to add them to your .gitignore_global. There are many editors and more to come, let developers use what they want and hold them responsible for not cluttering the repo.

@vpanjganj vpanjganj added this to the Maintenance milestone Jul 22, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants