You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Include other editors than JetBrains in the .gitignore #20
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.
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:
... 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.
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
changed the title [-]Include other editors that JetBrains in the .gitignore [/-][+]Include other editors than JetBrains in the .gitignore [/+]on 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.
Reacted by Vahid Panjganj, Piper McCorkle, Alma Sanchez and Enrique Bermúdez
@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 :)
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.
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.
Reacted by Antony Jones, Vahid Panjganj, Piper McCorkle and Franklin Yu
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...)
Reacted by Cristian Pallarés, Alma Sanchez and Franklin Yu
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.
Working in different companies and various teams, I've noticed not many
have a .gitignore_global and for that reason, I think we shouldn't fully
ignore editor settings.
@vpanjganj whoops, sorry that's my bad. I didn't notice that in the existing
.gitignore.
Yes, agreed. Let's stick to JS projects. I was just trying to get a point
across. 😊
As for major JS IDEs, Webstorm comes to mind, but I can't think of anything
else. Editors however, there are many. Almost an endless list.
To ignore Node stuff, we can just do a gitignore.io/api/node. That's what I do
for my personal projects.
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?
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.
Reacted by Cristian Pallarés, Ives Laaf, Franklin Yu, Claudius Coenen and Enrique Bermúdez
Activity
vpanjganj commentedon Jul 6, 2017
Yes, please go ahead, thanks.
bluepeter commentedon Jul 6, 2017
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 commentedon 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 commentedon Jul 6, 2017
@bluepeter What do you suggest? Maybe we can promote one of these
.gitignoregenerator tools?bluepeter commentedon 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:
... 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 commentedon 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
[-]Include other editors that JetBrains in the .gitignore [/-][+]Include other editors than JetBrains in the .gitignore [/+]antony commentedon 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 commentedon Jul 6, 2017
The reason I put editors in there was based on my own experience. I had to delete someone else's
.ideafolder from repos.antony commentedon Jul 6, 2017
@vpanjganj and I absolutely have experienced the same thing - but rather than pollute
.gitignoreI 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 commentedon Jul 6, 2017
I see the need to ignore
.ideaand 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 usingvscode? In that case, it makes sense to push.vscodeto enhance the developer environment.I actually agree with @bluepeter on this one. From what I understand, that
.gitignorewas 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.gitignorefor 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.gitignorefile into smaller chunks and point to the different.gitignores according to the project needs and requirements.Thoughts?
skyrpex commentedon 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 commentedon Jul 6, 2017
I think the current config for
vscodehandles that. You most likely want to pushtasks.jsonetc...I agree with that as well, I think this file should be trimmed down.
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:
.gitignore,node,javascriptusuals (node_modules, *.log, etc...)vpanjganj commentedon Jul 6, 2017
@skyrpex
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
.gitignoreand then as you said, add the usual ones (node_modulesetc...)antony commentedon 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 commentedon Jul 6, 2017
vpanjganj commentedon Jul 8, 2017
Hey guys, What do you think of this as a quick fix?:
Any thought?
@antony Sounds like a good idea do you think you can come up with something?
yeskunall commentedon Jul 8, 2017
@vpanjganj looks much, much better than the original
.gitignore!antony commentedon Jul 9, 2017
@vpanjganj I'll have a go yeah
MichalZalecki commentedon Jul 16, 2017
New proposal for
.gitignoreis 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.