wallabag/.gitignore

# Cache, logs & sessions
/var/*
!/var/cache
/var/cache/*
!var/cache/.gitkeep
!/var/logs
/var/logs/*
!var/logs/.gitkeep
!/var/sessions
/var/sessions/*
!var/sessions/.gitkeep
!var/SymfonyRequirements.php
/bin/*
!/bin/console
!/bin/symfony_requirements

# Parameters
/app/config/parameters.yml

# Managed by Composer
/vendor/

# Assets and user uploads
/web/bundles/
/web/uploads/

# Build
/app/build
/build

# Composer PHAR
/composer.phar

# Data for wallabag
data/assets/*
data/db/wallabag*.sqlite

# Docker container logs and data
docker/logs/
docker/data/

# To avoid crazy stuff on some PR, we must manually FORCE ADD IT on each new release
composer.lock
Switch to Symfony 3 structure 2016-01-14 18:15:07 +01:00			`# Cache, logs & sessions`
			`/var/*`
			`!/var/cache`
1st implementation of wallabag api, yeah 2015-01-28 17:09:27 +01:00			`/var/cache/*`
			`!var/cache/.gitkeep`
Switch to Symfony 3 structure 2016-01-14 18:15:07 +01:00			`!/var/logs`
			`/var/logs/*`
1st implementation of wallabag api, yeah 2015-01-28 17:09:27 +01:00			`!var/logs/.gitkeep`
Switch to Symfony 3 structure 2016-01-14 18:15:07 +01:00			`!/var/sessions`
			`/var/sessions/*`
			`!var/sessions/.gitkeep`
			`!var/SymfonyRequirements.php`
Remove binary from repo Since Composer 1.2, binaries are re-installed from vendors if there aren't found. This avoid us to commit binaries vendors into the repo. :warning: You have to update your Composer to the 1.2 (`composer selfupdate`) 2016-07-20 10:44:46 +02:00			`/bin/*`
			`!/bin/console`
			`!/bin/symfony_requirements`
1st implementation of wallabag api, yeah 2015-01-28 17:09:27 +01:00
			`# Parameters`
			`/app/config/parameters.yml`

			`# Managed by Composer`
symfony is there 2015-01-22 08:30:07 +01:00			`/vendor/`

1st implementation of wallabag api, yeah 2015-01-28 17:09:27 +01:00			`# Assets and user uploads`
			`/web/bundles/`
			`/web/uploads/`
symfony is there 2015-01-22 08:30:07 +01:00
Simplify build system 2015-03-03 19:20:08 +01:00			`# Build`
			`/app/build`
			`/build`
symfony is there 2015-01-22 08:30:07 +01:00
1st implementation of wallabag api, yeah 2015-01-28 17:09:27 +01:00			`# Composer PHAR`
			`/composer.phar`
change gitignore, last time, I promised 2015-01-28 13:28:12 +01:00
1st implementation of wallabag api, yeah 2015-01-28 17:09:27 +01:00			`# Data for wallabag`
			`data/assets/*`
Add LiipThemeBundle Re-defined the config / user relation to be OneToOne bidirectionnal. ConfigType is now a service so I can inject the list of available themes that are also used by LiipThemeBundle Force sqlite for test In case of people use a different driver in parameter.yml (yes I do :)) 2015-02-23 22:55:06 +01:00			`data/db/wallabag*.sqlite`
Add basic docker-compose configuration 2016-01-09 14:47:32 +01:00
Add Docker configuration for Postgres and MariaDB 2016-01-09 17:27:21 +01:00			`# Docker container logs and data`
Add basic docker-compose configuration 2016-01-09 14:47:32 +01:00			`docker/logs/`
Add Docker configuration for Postgres and MariaDB 2016-01-09 17:27:21 +01:00			`docker/data/`
Ignore composer.lock Having a big composer.lock on a final project can have side effect on incoming PR that add a new vendor. Mostly because conflict are too frequent. By ignoring composer.lock we ease the PR submission and rebase. BUT we need to be careful when we release a new version of wallabag. We should manually `git add -f composer.lock` to update it. Since composer.lock will no longer be commited I switch the `composer install` to a `composer up` in the travis configuration. 2016-01-20 18:49:45 +01:00
			`# To avoid crazy stuff on some PR, we must manually FORCE ADD IT on each new release`
			`composer.lock`