Jekyll/GitHub workflow with hidden drafts?

[ndarville]

I am thinking about doing a blog/site with multiple authors, and while I would like for the site to be open source (at least the majority of it), I would prefer the drafts remained hidden, and that, when published as posts, their edit history would be erased from before they were published.

private repo:
  - _drafts/ (w/ edit history)

public repo:
  - _posts/ (w/ edit history)
  - (...)

Assuming everything is hosted on GitHub, but deployed to S3 (to support custom domains), what would be the best way to do this?

And which publication hook would fit the best for automating this process as much as possible?

[mscharley]

gitignore the drafts folder? Will more than one person be working on the
same draft? Also, for what it's worth, GitHub Pages supports custom domains
via a CNAME file in the repo. See
https://help.github.com/articles/setting-up-a-custom-domain-with-github-pages

On 4 May 2014 18:56, ndarville notifications@github.com wrote:

I am thinking about doing a blog/site with multiple authors, and while I
would like for the site to be open source (at least the majority of it), I
would prefer the drafts remained hidden, and that, when published as posts,
their edit history would be erased from before they were published.

private repo:

• _drafts/

public repo:

• _posts
• (...)

Assuming everything is hosted on GitHub, but deployed to S3 (to support
custom domains), what would be the best way to do this?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/27
.

[ndarville]

One person will mainly focus on the draft, but I still want it to be a collaborative process where people comment using the Issues system and helps out in other ways—not to mention if the process involves editors, graphic department, fact-checking, proofing, and so on.

So syncing the draft centrally is still important.

[mscharley]

In that case, if you're using git, it will always see a removal from
_drafts and inclusion in _posts in the same commit as a 'move' operation as
git doesn't actually have a move/copy command it uses a heuristic to detect
when a file is copied/moved in the same commit based on the contents of the
files. Your best bet is probably to have one commit remove the file in
_drafts and another add it back into _posts if you really want to make
sure there's no history attached. My question would be why you want this
though.

On 4 May 2014 19:34, ndarville notifications@github.com wrote:

One person will mainly focus on the draft, but I still want it to be a
collaborative process where people comment using the Issues system and
helps out in other ways—not to mention if the process involves editors,
fact-checking, and proofing. So syncing the draft is still important.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/27#issuecomment-42128632
.

[mhulse]

I wonder if you could put the drafts in a private repo (I think free accounts are allowed one private free of charge) and the use a symlink to pull drafts into the jekyll repo whilst using a.gitignore to keep _drafts from showing in commit history?

A more dumbed down approach could be something simular to above but use Dropbox to share the drafts with collaborators?

[ndarville]

Yeah, if the .gitignore thing works with importing the private repo as a submodule or some such, that’d probably work pretty well.

[mhulse]

You could maybe use a git submodule but I've found that symlinks are pretty handy in terms of instantaneous updates. Not sure, though, how Jekyll will handle symlink to outside repo/files?

[mhulse]

On the other hand, if you don't need to instantaneously preview the drafts on the local site, a submodule might be best (like you're already saying). 😄

[ndarville]

True, it does mess with the ease of viewing the editing history. A submodule probably isn’t the way to go.

[doktorbro]

@ndarville Read this one jekyll/jekyll#1469 (comment)

[troyswanson]

Going to close this as it seems to be pretty well solved.