wallabag/.gitignore
Jeremy Benoist 173629a400 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

40 lines
609 B
Text

# 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
# 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