website
website copied to clipboard
Styles should be pulled out into a separate project/git submodule
This will make it easier to use the elementary frontend CSS framework ("elementary.css") without having to either:
A) direct link to elementary.io/styles/main.css
, as one project currently does
B) copy/snapshot the CSS from this repo and manually keep it up to date.
Git submodules are designed to solve this problem. We should use one :)
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
I'm not massively familiar with sub-modules, but I recall hearing that they cause a few issues. A cursory Google shows some negative results on the first page for "git submodule". They are a pain to maintain.
https://codingkilledthecat.wordpress.com/2012/04/28/why-your-company-shouldnt-use-git-submodules/ http://ayende.com/blog/4746/the-problem-with-git-submodules http://somethingsinistral.net/blog/git-submodules-are-probably-not-the-answer/
What would you propose instead?
Sent from my iPhone
On Jul 23, 2015, at 17:10, Lewis Goddard [email protected] wrote:
I'm not massively familiar with sub-modules, but I recall hearing that they cause a few issues. A cursory Google shows some negative results on the first page for "git submodule". They are a pain to maintain.
https://codingkilledthecat.wordpress.com/2012/04/28/why-your-company-shouldnt-use-git-submodules/ http://ayende.com/blog/4746/the-problem-with-git-submodules http://somethingsinistral.net/blog/git-submodules-are-probably-not-the-answer/
— Reply to this email directly or view it on GitHub.
I think a repository containing a stylesheet and a couple of test pages with plenty of elements is a good idea, but I don't think there's a need to version manage it. Automatically pulling it in could break stuff, so we could just version it and do it manually, which seems like it would cause far less headaches.
What you just described is how git submodules work :)
I mean I would like to pull in just 1 file, only when I choose, from another repository. That doesn't seem like it should need an entire new pattern when people want to propose changes.
like I said, that's how submodules work, and they're used very widely. Maybe we're not on the same page here —you're proposing is having a separate repository, and every time we want to bump to latest we need to:
- switch to a different repo
- fetch and pull latest changes from origin
- manually copy the file we want from this repo into the original repo
-
git add <new file>
-
git commit -m "bump theme file"
Instead of:
-
git submodule update
I wonder if we could just use an actual package manager (bower or npm or something) to depend on the theme? That's probably the cleanest abstraction and everyone already understands how they work (unlike git submodules, which are definitely not the most intuitive part of git... which is saying a lot)
You wouldn't need to pull the repo, just download that one file, then file a merge request like we do for translations or chart updates. It seems unnecessary for us to include an entirely new packaging mechanism for one stylesheet, especially since we could link to something like JSDelivr, and have all our properties update automatically.
Ultimately, so long as updating is well documented, I'm not opposed to any method.
Personally I think a git submodule would be a better route because if we add a package manager, not only does mvp have yet another development dependency, but every other project that uses the style does as well.
While we are at it, I think this would be a good chance to look through all the css, and fix some of the weird issues it has. But I would wait until webkit2 midori lands in elementary so we can drop support for some of the old browsers.
Seeing as we are now including the icons via a git submodule, and WebKit2 is in Epiphany (although we will need to support Freya for a while), this might be viable.