Gitbook deletes the output directory

[flaviut]

If deletion is necessary, Gitbook should only delete the files that need to be deleted for the build to occur. Deleting the entire directory can cause data loss if the output directory is misconfigured. For example, naively using ./ as the output directory might lead to things such as the loss of unpushed changes.

Duplicate of #106, but that seems to have been closed a while ago.

[stanch]

Also see #255.

[tbris84]

What kind of bs is this? I select the directory I want the new book to be placed in and it takes it upon itself to delete every file in the directory? I'm assuming there is no way to recover these unwanted deletions.

[jdmaresco]

Is there a reason this issue has remained open for so long? I have my Gitbook raw files in one folder and then build to another external folder which is a separate git repository. I use this setup so that I can push my built site to a gh-pages branch and deploy my book that way. Everytime I deploy, the build command actually deletes everything, including the .git folder.

Am I missing something? I'd consider putting in a pull request but wanted to understand if there's history to this request that I may be missing.

[AaronO]

@jdmaresco It was originally designed this way, because it's the easiest way to ensure that the build is "clean" (only contains the needed output files and none other). That's the advantage and goal of this strategy. (This avoids your gh-pages branch containing old/unused files).

The alternative isn't so obvious, you have to handle conflicts (how exactly should GitBook decide which files are safe to override and which aren't).

In your use case of deploying via gh-pages, you can use grunt-gitbook with a Gruntfile to do the push for you. Or simply via a shell similar to :

gitbook build -o /tmp/some_tmp_dir && \
    cd ~/git/your_gh_branch/
    cp -R /tmp/some_tmp_dir/* ./ && \
    git add . && git commit -m "Release update" && \
    git push

We provide automated builds via GitBook.com, it works nicely with GitHub via WebHooks (you can also push directly to GitBook.com like you would for Heroku).

So in practice it's not really a common pain since it's solved by either Grunt/shell tasks or via automated builds through GitBook.com.

jekyll actually does the same, even though it has a "cleaner module", the only thing it keeps in the output folder is .git and .svn (see https://github.com/jekyll/jekyll/blob/master/lib/jekyll/cleaner.rb#L90).

I guess we could take that approach, that would be cleaner/better for your workflow (though you might want to look into automated builds through GitBook.com).

@SamyPesse Is finishing off the 2.0.0 release, so it might make sense to get this done as part of that.

[SamyPesse]

Ok, I'm looking to fix this issue on the 2.0.0 release

[jdmaresco]

@AaronO – the rationale makes sense, as do your alternate solutions, but I think the Jekyll-style solution is good, and I'm glad to see @SamyPesse is looking at rolling into 2.0. Thanks guys, really appreciate your responsiveness.

[AaronO]

@jdmaresco I think it's better to do a full clean while preserving a restricted whitelist of files/folders like .git/.gitignore/.svn. That's what jekyll does and what gitbook will now do from 2.0.x.

I think it's the right pragmatic balance.