Hi,
Need suggestions from folks for .gitignore file, Here is my file looks like.
The goal is to get the success of getting rid of autogenerated files and cached files.
cache/
suitecrm.log
config.php
*.ext.php
upload/
*.log
config_override.php
Whats wrong with the default one?
## First part from https://github.com/github/gitignore/blob/master/SugarCRM.gitignore
# Ignore custom .htaccess stuff.
/.htaccess
# Ignore large parts of the annoying cache directory without breaking things.
cache/*
upload/*
!upload/index.html
# Ignore some files and directories from the custom directory.
custom/
custom/history/*
custom/blowfish/*
custom/modulebuilder/*
custom/working/*
custom/modules/*/Ext/
custom/modules/unified_search_modules_display.php
# Ignore AOD indexes
modules/AOD_Index/Index/*
install/status.json
# Configuration files should be ignored.
/config.php
/config_override.php
/config_si.php
tests/config.test.php
# Connector configuration should also be ignored.
custom/modules/Connectors/connectors/sources/ext/*/*/config.php
# Logs files can safely be ignored.
*.log
## IDE specific items
# Eclipse
*.pydevproject
.project
.metadata
bin/**
tmp/**
tmp/**/*
*.tmp
*.bak
*.swp
*~.nib
local.properties
.classpath
.settings/
.loadpath
# Emacs
*~
\#*\#
/.emacs.desktop
/.emacs.desktop.lock
.elc
auto-save-list
tramp
# IntelliJ Idea
*.iml
*.ipr
*.iws
.idea/
.phpstorm.meta.php
# NetBeans
nbproject/
# Vim
.*.sw[a-z]
*.un~
Session.vim
tags
# Windows
Thumbs.db
Desktop.ini
.DS_Store
.DS_Store?
# Microsoft Visual Studio
*.sln
*.suo
*.phpproj
# Disytel
lang_cmp.php
.kdev4/
SuiteCRM.kdev4
#Ignore composer vendor folder
vendor/
public/
#Ignore bower_components
bower_components/
node_modules/
#Ignore Sass Generated files in SuiteP
themes/SuiteP/css/*.map
themes/SuiteP/css/*/*.map
themes/SuiteP/css/*/color-palette.css
themes/SuiteP/css/*/variables.css
tests/_output/*
#Ignore browserstack
BrowserStackLocal
browserstack.err
cache/
custom/**/
.sass-cache/
.php_cs.cache
# Ignore testing environment
build/tmp/
# IMAP testing
fakeImapResource
include/Imap/ImapTestSettings.txt
# Ignore custom codeception environments so they won't be committed.
tests/_envs/custom.yml
codeception.yml
# Ignore dotenv files so they don't get commited to git.
# Only .env.dist should be committed.
.env
.env.test
.env.dev
Remember you can also use .git/info/exclude to have an additional, local, gitignore, that doesn’t get committed anywhere. This way you can keep your own gitignore without messing with other (upstream) gitignores.
My IDE (PhpStorm) taught me about this the other day…
Where is this “default” file from?
It looks like it’s been modified, and I’m not sure I understand the reasoning behind the patterns. Ex, if you have a line that’s custom/ why follow that with custom/history/* and the other more specific lines? Same with cache/* at the top and then cache/ under browserstack comment.
I’m still learning .gitignore patterns and trying to understand the logic in this file since I’m attempting to cleanup the ignores for our install. https://linuxize.com/post/gitignore-ignoring-files-in-git/ is a pretty good break down, but looking at this file I’m confused.
Default file is the one you get from cloning down the SuiteCRM repo, here the specific file on the repo here: https://github.com/salesagility/SuiteCRM/blob/master/.gitignore
In regards to you second question I’m not sure, @pgr maybe able to shed some light?
I don’t know much about this.
I would assume that custom/ isn’t the same as custom/*
The first one probably only excludes files at that level, and that explains why there are different entries for some of the lower levels.
Unrelated - I think we should add
custom/application/*/Ext/
That URL I shared suggests that custom/ would ignore that directory, and include all subdirectories. So custom/* would cover just the files within the custom directory, but nothing in child dirs.
If the pattern ends with a slash, it matches only directories. When a directory is ignored, all of its files and subdirectories are also ignored
I think the cache duplicates is similar, but likely an accident. the cache/ is under the Browserstack comment, but would technically apply to any folder anywhere that’s named “cache” and also ignore all those sub folders.
Agreed, we are currently with an inconsistent **.gitignore **
We first have cache/* which ignores only files directly at the first level of cache dir.
Then later on we have cache/ (under Browserstack section, which is misleading for the current purposes) which ignores everything that the above ignores, and further ignores all the levels below…
Note this old article is a bit out of date, but not completely: The cache directory and why you can’t just delete it
academe.co.uk/2012/06/sugarcrm-cache-directory-it-is-not-a-cache-directory
It’s important to read it before any considerations about the cache directory. Although I think all that is more relevant to the decision of when to delete the folder or not, and is probably less relevant (or irrelevant) to the gitignore decisions we’re discussing here.
What’s wrong with default one? When the last time you checked it? It is a complete and utter mess! Duplicates, wrong entries (e.x. whole custom/ directory are ignored!). And the last but not least - default Extension files are not ignored and the system really need them to deploy from scratch. This all makes my life so painful, because you can’t just make a simple and working CI/CD. There will be always the problems with those pesky .ext.php files. That’s how I ended up here - trying to google if someone solved that ugly nonsense schematics before me.
P.S. I am strongly convinced that any mechanics relying on repository files changing should be completely removed from the system. Without hesitation.
Current so-called “Extension framework” are just plain and stupid copy-pasting from a bunch of files to just one. There are no any difference for a performance, but a huge impact for a development comfort.
P.P.S. Also for example, check those 2 commits which, as it seems, added custom directory to .gitignore twice and by mistake.
Hi @Ashcraft,
Fair enough 
Agreed there are some issues kicking about with it, if you have any suggestions or end up updating you own and want to share it with the community im sure a discussion thread or PR on the github would be appreciated!
Thanks!,
Mac