Allow user to add commit message interactively

[jdblischak]

Similar to Git, if the user does not provide a commit message, we can prompt in the R console for a message. The recommendation is to use readline (SO answer).

The limitation is that readline only accepts a single vector, so it finishes once the user types Enter. To allow multi-line messages, we'd have to add that infrastructure.

Credit for good idea to @pcarbo.

[jdblischak]

For a simple interface, this would allow the user to enter a commit message. This will be a bit awkward with screens that are not wide, because R line wraps the enter text to line up with the end of the prompt.

if (is.null(message)) {
  message <- readline("Please enter a commit message (and then press ENTER): ")
}

For example, with an 80-character wide R console, it looks like this:

> message <- readline("Please enter a commit message (and then press ENTER): ")
Please enter a commit message (and then press ENTER): This is the commit message and 
                                                      it gets line wrapped where the
                                                      prompt ends.
> message
[1] "This is the commit message and it gets line wrapped where the prompt ends."

[jdblischak]

Note that the line wrapping does not occur in the R console run in the Terminal. The above was performed in RStudio 1.0.143 on Ubuntu 17.04.

[pcarbo]

@jdblischak Would this work?

readline2 <- function (message) {
  cat(message,"\n",sep="") 
  return(readline(""))
}
readline2("Please enter a commit message (and then press ENTER):")

[jdblischak]

@pcarbo Yes, your wrapper works much better

[jdblischak]

This can be added to wflow_git_commit() at this location:

https://github.com/jdblischak/workflowr/blob/13495cb7f54c77a31bc92d0a42ea7a096169c655/R/wflow_git_commit.R#L94-L101

If the message is left as NULL (the default), first ask the user if they would like to interactively add a commit message. If they choose not to, then have the code proceed to create a message from the function call (which is what deparse(sys.call()) does).

[pcarbo]

@jdblischak Thank you for brining up this issue (which is now quite old!). This is one of the top things I would like improved, in part because writing useful commit messages is so important, and we should make sure workflowr encourages this. Further, I don't think that these sort of changes would cause issues for existing users.

Here is a description of what I think would be the ideal behaviour (a reminder to readers that wflow_publish generates two commits):

• The first commit message can either be entered with the commit argument, or interactively (when commit = NULL or length(trimws(commit)) == 0).

• The first commit message is not optional (just as it is not optional in git); wflow_publish will halt if an empty commit message is provided.

• The second commit message is automatically generated based on the wflow_publish call. Here I do believe that we can improve over the existing (and largely uninformative) commit message, Build site, and I don't think it would be very hard to do so, e.g., Render webpages setup.html and analysis.html from R Markdown source setup.Rmd and analysis.Rmd, with seed = 1.

[pcarbo]

Following from discussion with @jdblischak and @stephens999 yesterday: It was discussed that a good compromise solution is to require a first commit message, but provide an informative default message that can be used, e.g., "Revise analysis.Rmd".

[jdblischak]

@pcarbo Thanks for summarizing our discussion!

For closing this Issue, let's first focus on the implementation of allowing the user to enter the commit message interactively in the R console. Once that is done, then we can return to the decisions on what information the default commit messages should contain (I probably open a new Issue to continue that discussion).

[pcarbo]

@jdblischak Fine with me.

[pcarbo]

Then we can return to the decisions on what information the default commit messages should contain.

@jdblischak As I work through the manuscript draft, I'm starting to think that providing good default commit messages is a very important design decision for workflowr---it goes along with one of our main aims, which is to provide a workflow for using git in a data analysis project. (But I do agree it doesn't have to be addressed in this issue. I just wanted to jot down my thought here.)