mirror of
https://github.com/wallabag/wallabag.git
synced 2024-05-16 08:12:39 +00:00
173629a400
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.
41 lines
609 B
Plaintext
41 lines
609 B
Plaintext
# 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
|