gitignores and git workflow

[jennybc]

I have started a bookdown project by cloning this:

https://github.com/rstudio/bookdown-demo

And am also scrutinizing source vs. rendered for hadley/r4ds and csgillespie/efficientR to figure out what the heck I'm doing.

Is there advice on what we should gitignore? The .gitignore file in the demo bears little resemblance to what people seem to be doing in real life.

Any or all of this would be great: advice here, advice in Bookdown: Authoring Books with R Markdown, or different (more realistic) .gitignore in the demo project. I'm hoping for info on what's source vs output vs vendored, what I could safely delete + rebuild, etc. I can make good guesses but it's alot to take in...

[znmeb]

I'm actively developing a book in Bookdown. It's not quite live yet so you can't look at code yet, but it will be sometime the middle of the week. Meanwhile, here's the .gitgignore I'm currently using:

.Rproj.user
.Rhistory
.RData
.*.Rnb.cached
_publish.R
_book

IIRC everything except _book was copied from the template book https://github.com/rstuido/bookdown-demo. I can probably do a "git log" and find out what other non-content changes I made during the migration from bookdown-demo to my book if that's any help.

[jjallaire]

You don't actually need .*.Rnb.cached anymore (that was a notebook thing
that is no longer in play). I'll update the template.

On Sun, Jun 5, 2016 at 1:42 PM, M. Edward (Ed) Borasky <
notifications@github.com> wrote:

I'm actively developing a book in Bookdown. It's not quite live yet so you
can't look at code yet, but it will be sometime the middle of the week.
Meanwhile, here's the .gitgignore I'm currently using:

.Rproj.user
.Rhistory
.RData
.*.Rnb.cached
_publish.R
_book

IIRC everything except _book was copied from the template book
https://github.com/rstuido/bookdown-demo

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#129 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AAGXxxCQfdIRP1h71HhN7bjlD5C8w2X5ks5qIwqigaJpZM4IuZN3
.

[coatless]

@jennybc

For a default build that is bare-n-bones see:

https://github.com/coatless/statprogramming

GitHub ignore:

.Rproj.user
.Rhistory
.RData
.Ruserdata
_book

Slightly more content:

https://github.com/coatless/timeseriesisgreat

And even more content as it goes live in under a week:

https://github.com/daviddalpiaz/appliedstats

These are all setup to autodeploy to GitHub pages via Travis-CI, so we have:

https://coatless.github.io/statprogramming

https://coatless.github.io/timeseriesisgreat

https://daviddalpiaz.github.io/appliedstats

[jennybc]

Thanks for the examples @znmeb @coatless!

I am ambivalent about gitignoring _book but perhaps it is for the best. With something like this, it can be hard to figure out what changes about the rendered result, as a consequence of a specific changes to source. If _book is in the repo, the diff will show you. If _book is gitignored, you've just got your own eyeballs and patience to click around and explore the result. For generating plain text from plain text, I don't think the prohibition against putting downstream products under version control necessarily applies.

But I do want to gitignore stuff that is non-diff-friendly (so maybe _book/_main.pdf and _book/_main.epub?) and/or a dependency (_book/libs).

[csgillespie]

@jennybc As an aside, we started our book when bookdown was in it's infancy. So our gitignore and general structure is an example of evolution, instead of a grand plan.

[znmeb]

@jennybc How big is the book? Mine's still small and young and not in need of me losing sleep over continuous integration. My workflow typically is as many small changes / commits as I can keep in my head, "Clean all", "Build Book", open a shell, "cd _book; netlify deploy". I went "live" yesterday so people can watch it happen.

[jennybc]

@znmeb I'm trying this out on something small (a tutorial for useR). But I need to rethink the STAT 545 content, so this also serves as a pilot study for that. In that case I would want to deploy via continuous integration. In STAT 545 I also get a lot of nontrivial contributions from others (e.g. from TAs), hence my desire to make it easier to understand the implications of proposed changes to source.

[znmeb]

@jennybc I'll be opening up my book source repo in the next day or so. It's on GitLab now but I need to move it here because Netlify can't pull from GitLab. I probably should have put it here to begin with, since the "Edit" links were designed for GitHub fork / pull request workflows.

[coatless]

@jennybc

If you plan to use travis-ci to auto-deploy to GitHub pages, then the _book output is made available in the gh-pages branch.

See:

https://github.com/daviddalpiaz/appliedstats/commits/gh-pages

and

Auto-output Commit:
daviddalpiaz/appliedstats@0cfdc52

Code commit:
daviddalpiaz/appliedstats@a240bd6

The benefit of removing the _book output from the main repository is:

1. Avoid bloat (e.g. duplicate images)
2. Retain only code changes used to generate the renders in main repo and generate results in another repo.
3. Faster clone times

[znmeb]

OK - my repo is live: https://github.com/znmeb/mastering-dfs-analytics-bookdown.

[yihui]

What I do is similar to @coatless: Rmd source files in master, and HTML output in gh-pages, so I can see changes in both source and output if I want.

[jennybc]

@coatless and @yihui: thanks to you both for specific example repos above. That allowed me to successfully deploy to gh pages via travis.

[github-actions]

This old thread has been automatically locked. If you think you have found something related to this, please open a new issue by following the issue guide (https://yihui.org/issue/), and link to this old issue if necessary.