Skip to content
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

Cleanup git history of large files (bower_components) #52

Open
grimen opened this issue Jan 11, 2016 · 8 comments
Open

Cleanup git history of large files (bower_components) #52

grimen opened this issue Jan 11, 2016 · 8 comments

Comments

@grimen
Copy link
Contributor

grimen commented Jan 11, 2016

Git tree is ~30 MB large even though the project is very simple, this is because bower_components is still in the Git tree which makes no sense - cloning forever. I removed it from versioning in my fork, but didn't do the actual version histoy cleanup using git filter-branch --tree-filter 'rm -rf bower_components' --prune-empty HEAD because that require the project maintainer to be aware. Read more here: https://help.github.com/articles/remove-sensitive-data/

@thomaspark
Copy link
Owner

The reason Bower components are tracked is because the project site is hosted through GitHub. This is also why there's just a single gh-pages branch (#51). Normally I would agree about both of these suggested changes.

See: https://help.github.com/categories/github-pages-basics/

@grimen
Copy link
Contributor Author

grimen commented Jan 11, 2016

@thomaspark The best practice for that is to use a build task that compiles into dist the files you need. Having an entire tree of bower components hanging in versioning will only cause troubles, no upside of it really.

I could do a neat Grunt task for this if you agree on it.

@thomaspark
Copy link
Owner

@grimen, I am open to a Grunt task that handles copying over the necessary files.

Appreciate all your comments and PRs. Busy at the moment, but I'll go through your PRs and merge them in soon, probably next week.

@grimen
Copy link
Contributor Author

grimen commented Jan 11, 2016

Sure, I could do a PR proposal.

I find a lot of value in this project, it is really solving a problem for designers/developers. I actually got some more ideas/reflections that could add value without much visual change that I would love to discuss when you got more time.

@grimen
Copy link
Contributor Author

grimen commented Jan 19, 2016

Did a minimalistic solution using Grunt copy task. Later on Webpack makes sense when codebase is refactored, but as GlyphSearch is not modularized (ES6/CommonJS/AMD) that didn't make much sense.

@jerone
Copy link

jerone commented Jan 19, 2016

There is some discussion as to whether or not the bower_components folder should be committed. I like the solution mentioned by Ben Forrest on his post "Should you commit Bower components to Git?" where one .gitignore the bower_components contents and just un-ignore the vendor dist folders.

@grimen
Copy link
Contributor Author

grimen commented Jan 19, 2016

@jerone Assuming Bower components where designed the same way, they are not - Bower Components spec is a complete mess, everyone do their own file structure. Grunt copy task is much more clear IMO, keeping everything in one place.

@grimen
Copy link
Contributor Author

grimen commented Jan 19, 2016

@jerone @thomaspark probably can decide what is preferable for this project though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants