feat: Pull as part of finalize_version()

[maelle]

Fix #39

Not ready, I need some clarifications. (maybe a concrete example of a stage where pull=TRUE makes sense, as well as a concrete example of a stage where pull=FALSE makes sense).

[krlmlr]

Thanks. pull = FALSE is required if offline. I'm not sure we need it for the lower-level functions such as commit_version() .

[maelle]

I'm not sure we need it for the lower-level functions such as commit_version() .

So you'd prefer the code

  if (has_remote_branch(gert::git_branch()) && pull) {
    # is the local branch behind?
    if (gert::git_ahead_behind()$behind > 0) {
      # With pull = TRUE we would fetch always and always uncommit + commit if behind master
      gert::git_pull(rebase = TRUE)
    }
  }

to be directly in finalize_version()?

Another question: is the default pull = TRUE ok?

[krlmlr]

I'd wrap that code in a function and call it only from finalize_version(), perhaps.

Rethinking offline work. If we're offline, or if PATs are unset, everything should still work, but require opt-in. Otherwise, the default should be to require connectivity and PATs, and do everything that's needed to keep the work in sync. Perhaps we need bump_version(allow_offline = FALSE) ?

[maelle]

Rethinking offline work. If we're offline, or if PATs are unset, everything should still work, but require opt-in. Otherwise, the default should be to require connectivity and PATs, and do everything that's needed to keep the work in sync. Perhaps we need bump_version(allow_offline = FALSE) ?

Should this be a separate issue?

• asking users to confirm they want to use the function offline.
• allowing an easy "refresh" once they are online again (it'd probably be easier to unbump then rebump, actually).

One way to lose less information when offline is

• changing the settings of the merge & squash messages so that they are self-contained (as opposed to necessitating a call to GitHub API)
• #512

But offline, one would still not have the info on PR attribution. Maybe for that too it'd be good to ensure the info is stored in the commit messages via "Co-Authored-by".