f/revision

[mdavy86]

Summary

Example to enhance the date and shasum information by condensing to a 7 digit shasum, and adding a url to the github document revision. As this template is used at the top of multiple Rmarkdown documents, one idea could be to have one generic file and read it using read_chunk().

[stephens999]

Hi @mdavy86 thanks for the PR. I'm wondering whether your suggestions are best discussed as potential changes to the workflowr package that creates this template. @jdblischak ?

[jdblischak]

Interesting suggestion, @mdavy86. I had considered making the Git Sha1 a link. Automating this for any potential repo (especially considering the edge cases where the repo has not yet been created or if the repo is a fork) would require a decent amount of code.

This decision is directly relevant to workflowr issue 22. We were discussing how to make the template less dependent on having workflowr installed. One option is to make it completely independent of workflowr while still maintaining the ability to insert the SHA1. The other option would make it so that workflowr must be installed to add the SHA1, which would be required in this case since a workflowr function would need to be called.

[mdavy86]

I see, I should close this PR then as I didn't realize the templating came from workflowr. I have not used the github R package workflowr but have installed it now.

If a repository does exist in github, then the shasum probably needs to relate to the remote: origin, and current branch HEAD position to generate a suitable url.

##Find which branch is HEAD
> sapply(branches(), is_head)
       f/revision            master      ...
             TRUE             FALSE       ...

> repo <- init(".")
## In this case my fork is the origin
> remote_url(repo)[which(remotes() %in% "origin")]
[1] "https://github.com/mdavy86/fiveMinuteStats.git"
## Trailing content needs removing, and add /tree ...
dirname(remote_url(repo)[which(remotes() %in% "origin")])
[1] "https://github.com/mdavy86"

I have to have a decent look at git2r...

[jdblischak]

Thanks for the ideas for code implementation, @mdavy86. Since you are clearly knowledgeable about Git and R, please check out workflowr and let me know if you have any suggestions. Especially take a look at the vignettes (links in the README).

I think the most difficult part of implementing such a feature is guessing how each user wants to use workflowr. Inserting the remote repository specified by "origin" makes a lot of assumptions. First, it assumes that the repo has a remote repository with that name, which (although very likely) is not a requirement. Second, it would put restrictions on Pull Requests. For example, the "origin" may be the user's fork of a repo, which is ok if the upstream maintainer only wants Rmd files in PRs. But if they want both the Rmd and the HTML in the PR, this would not work.

Also, I don't think searching for HEAD is a good idea. GitHub Pages isn't that flexible. It will only serve the pages in one branch (workflowr is designed to be used with the option "master branch docs/ folder"). Thus it only makes sense to link to commits in the master branch. In general, workflowr is designed for the simplified workflow of just one branch. A user can of course choose to have a more complicated workflow with multiple branches, but then it is on the user to know enough Git to manage this complexity.