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

Split up release package & gh-pages build #231

Closed
franz-josef-kaiser opened this issue Mar 29, 2014 · 12 comments
Closed

Split up release package & gh-pages build #231

franz-josef-kaiser opened this issue Mar 29, 2014 · 12 comments

Comments

@franz-josef-kaiser
Copy link

The whole repo really needs a master and gh-pages branch with different contents:

  • gh-pages -> build for the actual docs page
  • master -> development source + dist directory that holds the gh-pages branch

Short intro on how to split this one up:

  1. Add a master branch: git branch -b master
  2. Add the branch to the GitHub repo: git push origin master (in case the remote repo is locally named origin - one can check that by using git remote -v).
  3. Switch to master branch: git checkout master
  4. Add a dist folder: mkdir dist
  5. Add the folder to the repo: git add dist && git commit -m "distribution folder added"
  6. Point the subtree from the dist folder to the gh-pages branch: git subtree push --prefix origin gh-pages

Done.

Now development can get split up between the actual releases and the page.

@LeaVerou
Copy link
Member

This is great, thanks! Will try to do it if I get some time.

@LeaVerou
Copy link
Member

Would I need to change any URLs in the files if I tried this? (pardon my ignorance, never used git subtree before)

@ghost
Copy link

ghost commented Jul 13, 2014

I'd like to give this a bump and offer to help, if necessary. Just had to go through diagnosing what was wrong with bower install prism not realizing bower install prism#gh-pages was required as the repo only has a gh-pages branch.

To get things a little more sane, the first thing you might want to do is just create a master branch and pull the current contents of gh-pages into it. After that, if the contents need to diverge (they probably should), let them. More importantly, though, I think it would help adoption if you just created the master branch and pulled the current gh-pages into it.

@LeaVerou
Copy link
Member

Hi Rob,

Thanks for offering to help. I don’t mind making the change, but I want something that won't add unnecessary future overhead for contributors. The Prism website currently has a downloader that needs access to all components to build the download. Therefore, the only way I see this working is if I can somehow point the master branch to be a subfolder of the website that updates automatically every time I commit to gh-pages. Themes and plugins though are on separate folders, so it gets more complicated. I really, really don't want to have to manually sync master and gh-pages after every single change though.

@ghost
Copy link

ghost commented Jul 13, 2014

Wouldn't you, instead, prefer to cut your downloads off master instead of
using gh-pages? Master is conventionally a release branch. You're cutting
your releases out of an odd branch, which is why there is so much tool
confusion.
On Jul 13, 2014 3:25 PM, "Lea Verou" notifications@github.com wrote:

Hi Rob,

Thanks for offering to help. I don’t mind making the change, but I want
something that won't add unnecessary future overhead for contributors. The
Prism website currently has a downloader that needs access to all
components to build the download. Therefore, the only way I see this
working is if I can somehow point the master branch to be a subfolder of
the website that updates automatically every time I commit to gh-pages.
Themes and plugins though are on separate folders, so it gets more
complicated. I really, really don't want to have to manually sync master
and gh-pages after every single change though.


Reply to this email directly or view it on GitHub
#231 (comment).

@franz-josef-kaiser
Copy link
Author

As I'm still subscribed to that ticket: A lot of tools (like package managers) are highly confused if there is no master branch.

Also: If you add a Gruntfile.js and explain your build process, people (like me) might jump in and help pulling off some automation :)

@ghost
Copy link

ghost commented Jul 14, 2014

A Gruntfile isn't really necessary, but would be great.

I may just fork this project and get it done. If Lea takes a pull back,
that'd be great. I can delete my fork. But, I want/need a Prism that
integrates into other things instead of always needing to be a manual
integration after visiting a web page to download a "build" that happens on
that server, then manually add to my local git and need to repeat the
process any time there's an update to Prism. Hassles.

I'd really rather integrate Prism as a Bower component, NPM module or even
a gem or whatever so that forward maintenance is automatic as updates
occur. I know it seems pretty trivial - it's not that big of a library,
etc. But, time spent on maintenance that is avoidable is wasted time. And,
with a little more work in this repo, that maintenance can be automatic.

Lea, you have two people now willing to jump in and help. Would you prefer
me/us to fork Prism and send you a pull request once we create a master
branch and integrate your build process in a way that also works for
integration systems?

-Rob

On Mon, Jul 14, 2014 at 2:43 AM, Kaiser notifications@github.com wrote:

As I'm still subscribed to that ticket: A lot of tools (like package
managers) are highly confused if there is no master branch.

Also: If you add a Gruntfile.js and explain your build process, people
(like me) might jump in and help pulling off some automation :)


Reply to this email directly or view it on GitHub
#231 (comment).

@zeitgeist87
Copy link
Collaborator

Wouldn't it be easier to just add a new branch master and keep it in sync with gh-pages, instead of using a subtree. Future commits would go to master and updating the webpage would look something like this:

  1. git checkout gh-pages
  2. git reset --hard master
  3. git push
  4. git checkout master

@LeaVerou
Copy link
Member

Well, that’s exactly what I don’t want to end up having to do. Keeping two things in sync manually is recipe for disaster.

@ghost
Copy link

ghost commented Jul 16, 2014

Forked. Thanks, Lea. I tried.
On Jul 16, 2014 8:45 AM, "Lea Verou" notifications@github.com wrote:

Well, that’s exactly what I don’t want to end up having to do. Keeping two
things in sync manually is recipe for disaster.


Reply to this email directly or view it on GitHub
#231 (comment).

@loganfranken
Copy link
Contributor

As I've been looking through the issues, this is a pretty hot topic (the whole gh-pages as the main branch over master debate): I think we might want to try and keep the discussion in one place.

I think #180 is where most of this talk is happening right now.

Maybe we can close this issue as a duplicate?

@Golmote
Copy link
Contributor

Golmote commented Jun 20, 2015

You're right. See #180 for discussion about this.

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

5 participants