Jekyll happily destroys all dot files when building the site

[jasonroelofs]

So I just lost about an hour's worth of work when I ran jekyll --no-auto . to try to figure out why my site wasn't generating. I had forgotten that the directory parameter is where to generate the site, so of course jekyll deletes what's in . and puts the generated files there. I initially didn't think it would have been a big deal, I'm using git, I've got commits waiting to push, I'll just git checkout everything again.

Nope, jekyll deleted my .git directory too. Work gone =/

[jasonroelofs]

It was an accident, I had forgotten that the dir parameter means "where to generate to" and was thinking "directory with files to generate the site from". I shouldn't be punished this harshly for an honest mistake.

[jasonroelofs]

It was an accident, I had forgotten that the dir parameter means "where to generate to" and was thinking "directory with files to generate the site from". I shouldn't be punished this harshly for an honest mistake.

[jasonroelofs]

I apologize if I somehow offended you, but the fact remains that Jekyll will happily delete absolutely everything in whatever directory you happen to specify as the _site dir (a most prominent feature, that being the first full parameter the jekyll executable looks for), which is a definite bug and needs to be fixed. For now I've forked jekyll and removed the offending code, but as I'm not fully aware of what's expected to be cleaned I'm not sure how much to fix up to offer a PR.

[jasonroelofs]

I apologize if I somehow offended you, but the fact remains that Jekyll will happily delete absolutely everything in whatever directory you happen to specify as the _site dir (a most prominent feature, that being the first full parameter the jekyll executable looks for), which is a definite bug and needs to be fixed. For now I've forked jekyll and removed the offending code, but as I'm not fully aware of what's expected to be cleaned I'm not sure how much to fix up to offer a PR.

[jasonroelofs]

Dude! I accidentally told Jekyll to treat my repository directory as the _site dir, then it deleted my .git directory. THAT IS A BUG. I don't know how you can't see this! A library should not make it easy to accidentally screw yourself over!

I also don't know why you are so intent on disproving me here or shutting me up. You're not even a contributor to this project and thus can't make these kind of decisions anyway. Seriously, what's your problem?

[jasonroelofs]

Dude! I accidentally told Jekyll to treat my repository directory as the _site dir, then it deleted my .git directory. THAT IS A BUG. I don't know how you can't see this! A library should not make it easy to accidentally screw yourself over!

I also don't know why you are so intent on disproving me here or shutting me up. You're not even a contributor to this project and thus can't make these kind of decisions anyway. Seriously, what's your problem?

[jasonroelofs]

Wow. I explain that this library breaks a well understood -nix rule of not deleting hidden files unless the library itself created said files, and because of this I get personally insulted? In case you haven't learned yet, Ad Hominem is not how you deal with disagreements.

The ruby community has enough problems with self-entitled and stuck-up jerks making things worse for the rest of us. Thanks for adding yourself to that list.

That said the more I think about what happened, the more I've come to realize that the problem is even deeper. You see @svnpenn, you said it yourself, Jekyll is a file generation library, why is it deleting files? I've been unable to find anything in the documentation, nothing in the wiki, and nothing in the help that says "this will blow away everything in the generated dir". A file generation library should not be deleting files, that goes completely against the entire expectation of using said library.

I'm going to go ahead and close this ticket as any further discussion has been permanently marred by @svnpenn's illogical hatred towards me and I'll have a new, better Pull Request ready in a bit.

[jasonroelofs]

Wow. I explain that this library breaks a well understood -nix rule of not deleting hidden files unless the library itself created said files, and because of this I get personally insulted? In case you haven't learned yet, Ad Hominem is not how you deal with disagreements.

The ruby community has enough problems with self-entitled and stuck-up jerks making things worse for the rest of us. Thanks for adding yourself to that list.

That said the more I think about what happened, the more I've come to realize that the problem is even deeper. You see @svnpenn, you said it yourself, Jekyll is a file generation library, why is it deleting files? I've been unable to find anything in the documentation, nothing in the wiki, and nothing in the help that says "this will blow away everything in the generated dir". A file generation library should not be deleting files, that goes completely against the entire expectation of using said library.

I'm going to go ahead and close this ticket as any further discussion has been permanently marred by @svnpenn's illogical hatred towards me and I'll have a new, better Pull Request ready in a bit.

[jasonroelofs]

FYI, and this is the last thing I'll say here, something being "by design" doesn't mean it's right.

[jasonroelofs]

FYI, and this is the last thing I'll say here, something being "by design" doesn't mean it's right.

[duijf]

I want to explore the concept of "childproofing" the generation process here.

@svnpenn You are acting like simply leaving random crap in the destination folder is the only option. A confirmation might be more of a compromise.

Such a prompt, however, might annoy some users, who want to save as many keystrokes as possible. The solution I can think of might be to only prompt for confirmation when the destination directory is not set by _config.yml.

In my opinion this is something that needs to be explored. You are right to say that there are a lot of outstanding bugs, but this would be fairly simple to implement for anyone, if we give it enough thought.

@jameskilton Excellent point. A better solution or design should always be sought after.

[duijf]

I want to explore the concept of "childproofing" the generation process here.

@svnpenn You are acting like simply leaving random crap in the destination folder is the only option. A confirmation might be more of a compromise.

Such a prompt, however, might annoy some users, who want to save as many keystrokes as possible. The solution I can think of might be to only prompt for confirmation when the destination directory is not set by _config.yml.

In my opinion this is something that needs to be explored. You are right to say that there are a lot of outstanding bugs, but this would be fairly simple to implement for anyone, if we give it enough thought.

@jameskilton Excellent point. A better solution or design should always be sought after.

[jamesgecko]

@svnpenn Flags are generally used to enable potentially destructive operations, not disable them.

[jamesgecko]

@svnpenn Flags are generally used to enable potentially destructive operations, not disable them.

[jamesgecko]

@svnpenn A path isn't a flag, and many unix commands have failsafes, so the behavior of the command is potentially surprising. For example, look at what happens when you try to rmdir a nonempty folder without flags. This is a pretty basic usability issue.

Either a refusal to accept the current directory as a destination (which pretty much nobody has actually ever wanted), or a check for a usual directory or file like _posts, _site or _config.yml in the destination directory before wiping it wouldn't be a terrible thing.

[jamesgecko]

@svnpenn A path isn't a flag, and many unix commands have failsafes, so the behavior of the command is potentially surprising. For example, look at what happens when you try to rmdir a nonempty folder without flags. This is a pretty basic usability issue.

Either a refusal to accept the current directory as a destination (which pretty much nobody has actually ever wanted), or a check for a usual directory or file like _posts, _site or _config.yml in the destination directory before wiping it wouldn't be a terrible thing.

[mdippery]

I agree with JamesGecko. A simple check to make sure the source and destination directories are not the same would be a good start; I highly doubt anyone has ever wanted to overwrite their source directory with Jekyll output.

[mdippery]

I agree with JamesGecko. A simple check to make sure the source and destination directories are not the same would be a good start; I highly doubt anyone has ever wanted to overwrite their source directory with Jekyll output.

[narkisr]

I think this is a valid use case where keeping .git in _site is required

http://blog.blindgaenger.net/generate_github_pages_in_a_submodule.html

[narkisr]

I think this is a valid use case where keeping .git in _site is required

http://blog.blindgaenger.net/generate_github_pages_in_a_submodule.html

[svnpenn]

@narkisr

With that method, it requires 3 commits for each new post. Whereas you could just maintain 2 independent branches a la

arademaker.github.com/blog/2011/12/01/github-pages-jekyll-plugins

[svnpenn]

@narkisr

With that method, it requires 3 commits for each new post. Whereas you could just maintain 2 independent branches a la

arademaker.github.com/blog/2011/12/01/github-pages-jekyll-plugins

[narkisr]

Its possible but its a bit more manual, then again its not like we push to
gh-pages every second

Ronen

On Fri, Apr 13, 2012 at 1:51 AM, Steven Penny <
reply@reply.github.com

wrote:

@narkisr

With that method, it requires 3 commits for each new post. Whereas you
could just maintain 2 independent branches a la

arademaker.github.com/blog/2011/12/01/github-pages-jekyll-plugins

---

Reply to this email directly or view it on GitHub:
mojombo#534 (comment)

[narkisr]

Its possible but its a bit more manual, then again its not like we push to
gh-pages every second

Ronen

On Fri, Apr 13, 2012 at 1:51 AM, Steven Penny <
reply@reply.github.com

wrote:

@narkisr

With that method, it requires 3 commits for each new post. Whereas you
could just maintain 2 independent branches a la

arademaker.github.com/blog/2011/12/01/github-pages-jekyll-plugins

---

Reply to this email directly or view it on GitHub:
mojombo#534 (comment)

[svnpenn]

I keep one git repo with 2 independent branches master and source. For each new post I make one commit to each. I think this is the simplest way.

github.com/svnpenn/dotfiles/blob/master/bin/jekyll-publish.sh

[svnpenn]

I keep one git repo with 2 independent branches master and source. For each new post I make one commit to each. I think this is the simplest way.

github.com/svnpenn/dotfiles/blob/master/bin/jekyll-publish.sh

[narkisr]

Im using (or at least trying to) http://jekyllbootstrap.com/ which seems to be depending on the jykell source being pushed into gh-pages and not just the generated site code, plusjade/jekyll-bootstrap#45

I agree that pushing just the _site is as simple as it gets.

Thank you

[narkisr]

Im using (or at least trying to) http://jekyllbootstrap.com/ which seems to be depending on the jykell source being pushed into gh-pages and not just the generated site code, plusjade/jekyll-bootstrap#45

I agree that pushing just the _site is as simple as it gets.

Thank you

[svnpenn]

The gh-pages moniker is only required for "project pages", ie narkisr.github.com/blah. A "user page" can be made with just the master branch, ie narkisr.github.com. Either way if you are creating a page with a custom jekyll, you are going to need 2 branches. One for the source and one for the generated site.

[svnpenn]

The gh-pages moniker is only required for "project pages", ie narkisr.github.com/blah. A "user page" can be made with just the master branch, ie narkisr.github.com. Either way if you are creating a page with a custom jekyll, you are going to need 2 branches. One for the source and one for the generated site.

[mustefa]

I just think it's awesome he wrote a pull request.

[mustefa]

I just think it's awesome he wrote a pull request.

[zephiro]

It has always bothered me that Jekyll mangles timestamps. When you run jekyll to regenerate your site, all timestamps are updated to the current time. (This is because all pages are regenerated—a separate and also annoying issue.) So to anything that uses timestamps to determine when a page has changed, it appears that every page changes whenever a single page changes.

The solution would be Jekyll, generate only the files that have changed and not all

[zephiro]

It has always bothered me that Jekyll mangles timestamps. When you run jekyll to regenerate your site, all timestamps are updated to the current time. (This is because all pages are regenerated—a separate and also annoying issue.) So to anything that uses timestamps to determine when a page has changed, it appears that every page changes whenever a single page changes.

The solution would be Jekyll, generate only the files that have changed and not all