New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

.gitignore sync #211

Closed
ogizanagi opened this Issue Dec 1, 2015 · 6 comments

Comments

Projects
None yet
4 participants
@ogizanagi
Member

ogizanagi commented Dec 1, 2015

I wonder why the installer have to recreate the .gitignore file instead of using the one provided in the symfony/standard-edition ?

The build script used to create the archive remove the .gitignore file. But it'll certainly be easier to maintain if was kept if the line was slightly different:

- rm -rf app/cache/* app/logs/* .git*
+ rm -rf app/cache/* app/logs/* .git/

(Also I'm not sure cache and logs directories should still be removed ?)

This method could then be removed. Currently, the generated .gitignore file for 3.0 for instance is not in sync with the latest changes:

1a2
> /bin/
3,6c4,7
< /phpunit.xml
< /var/*
< !/var/cache
< /var/cache/*

---
> /composer.phar
> /vendor/
> /web/bundles/
> /var/
8,9d8
< !/var/logs
< /var/logs/*
11,12d9
< !/var/sessions
< /var/sessions/*
14,16c11
< !var/SymfonyRequirements.php
< /vendor/
< /web/bundles/

---
> /phpunit.xml
@Pierstoval

This comment has been minimized.

Show comment
Hide comment
@Pierstoval

Pierstoval Dec 1, 2015

Contributor

👍 for this, the gitignore is already provided by the builder.

But it needs a new Symfony release for this :D

Contributor

Pierstoval commented Dec 1, 2015

👍 for this, the gitignore is already provided by the builder.

But it needs a new Symfony release for this :D

@ogizanagi

This comment has been minimized.

Show comment
Hide comment
@ogizanagi

ogizanagi Dec 1, 2015

Member

@Pierstoval : Not necessarily. Can't it be a new installer release only ? (And recreating an archive containing the .gitignore file for each maintained symfony/symfony-standard versions)

Member

ogizanagi commented Dec 1, 2015

@Pierstoval : Not necessarily. Can't it be a new installer release only ? (And recreating an archive containing the .gitignore file for each maintained symfony/symfony-standard versions)

@Pierstoval

This comment has been minimized.

Show comment
Hide comment
@Pierstoval

Pierstoval Dec 1, 2015

Contributor

It would need a Symfony Standard release because the build script generates the tarball which contains the "built" datas, so the .gitignore file is not present now, but would be if the script is updated and a new version is released (because tarballs are pushed to get.symfony.com on each release).
It's not the installer that removes the .gitignore file :)

I don't know if the Symfony team can (or would) execute manually the tarball builder script, but actually I wonder if we could find a workaround in the installer, for instance download the .gitignore from github raw files in the DownloadCommand...

What do you think?

Contributor

Pierstoval commented Dec 1, 2015

It would need a Symfony Standard release because the build script generates the tarball which contains the "built" datas, so the .gitignore file is not present now, but would be if the script is updated and a new version is released (because tarballs are pushed to get.symfony.com on each release).
It's not the installer that removes the .gitignore file :)

I don't know if the Symfony team can (or would) execute manually the tarball builder script, but actually I wonder if we could find a workaround in the installer, for instance download the .gitignore from github raw files in the DownloadCommand...

What do you think?

@ogizanagi

This comment has been minimized.

Show comment
Hide comment
@ogizanagi

ogizanagi Dec 2, 2015

Member

Personally, I feel like using a workaround in the installer would be useless, whereas updating the build script and the archives (and I mean recreate them through the updated script, of course) would be way more reliable.

I don't see the issue about regenerating the tarballs, but of course, I might not know all the implications behind :)

Member

ogizanagi commented Dec 2, 2015

Personally, I feel like using a workaround in the installer would be useless, whereas updating the build script and the archives (and I mean recreate them through the updated script, of course) would be way more reliable.

I don't see the issue about regenerating the tarballs, but of course, I might not know all the implications behind :)

javiereguiluz added a commit that referenced this issue Dec 10, 2015

bug #218 Keep .gitignore files in sync (ogizanagi)
This PR was merged into the 1.0-dev branch.

Discussion
----------

Keep .gitignore files in sync

This is only a quick fix regarding the issue mentioned in #211 , and the few recent issues related:

- #217
- symfony/symfony#16815

Commits
-------

0da1b95 Keep .gitignore files in sync
@xabbuh

This comment has been minimized.

Show comment
Hide comment
@xabbuh

xabbuh Dec 16, 2015

Member

Can we close here given that this must be fixed in the SensioDistributionBundle (see sensiolabs/SensioDistributionBundle#246)?

Member

xabbuh commented Dec 16, 2015

Can we close here given that this must be fixed in the SensioDistributionBundle (see sensiolabs/SensioDistributionBundle#246)?

@ogizanagi

This comment has been minimized.

Show comment
Hide comment
@ogizanagi

ogizanagi Dec 16, 2015

Member

Sure I think we can close it. Plus the new version of the installer now provides a workaround to keep the .gitignore files in sync, so having this issue opened doesn't make sense anymore.

Member

ogizanagi commented Dec 16, 2015

Sure I think we can close it. Plus the new version of the installer now provides a workaround to keep the .gitignore files in sync, so having this issue opened doesn't make sense anymore.

@ogizanagi ogizanagi closed this Dec 16, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment