Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should use_github_release() offer to push if needed? #1385

Closed
hadley opened this issue Mar 8, 2021 · 3 comments · Fixed by #1746
Closed

Should use_github_release() offer to push if needed? #1385

hadley opened this issue Mar 8, 2021 · 3 comments · Fixed by #1746
Labels
feature a feature request or enhancement git git, GitHub, and CI in general release 🛫

Comments

@hadley
Copy link
Member

hadley commented Mar 8, 2021

Rather than erroring, as currently.

@jennybc
Copy link
Member

jennybc commented Mar 8, 2021

I've definitely thought about this.

# TODO: consider offering to push for them?

Kind of related to some discussion in r-lib/gert#65 (which lead to gert::git_ahead_behind(), which we are already using).

I think I haven't leaped into action, just because I haven't done a full analysis of the situation where both local and remote have some unique commits. Do we ... attempt to pull with rebase, then push? What if there are merge conflicts?

@jennybc jennybc added the git git, GitHub, and CI in general label Mar 8, 2021
@hadley
Copy link
Member Author

hadley commented Mar 8, 2021

Maybe we could just push (without asking) if there are local commits missing from the remote, but if there are remote commits missing from local we'd still require the user to fix it up. (That said, I'm not actually sure what you're supposed to do in that scenario, so if we could figure it out, I'd love if it was automated)

@hadley
Copy link
Member Author

hadley commented Mar 8, 2021

Slightly related — should usethis::use_dev_version() also offer to push? It's almost always what you want.

@jennybc jennybc added this to the v2.1.0 milestone Sep 28, 2021
@jennybc jennybc removed this from the v2.1.0 milestone Oct 8, 2021
@hadley hadley added the feature a feature request or enhancement label Jan 17, 2023
@hadley hadley added this to the v2.2.0 milestone Jan 19, 2023
hadley added a commit that referenced this issue Jan 20, 2023
* `use_release_issue()` checks default branch and pulls automatically.
* `use_github_release()` automatically pushes, if safe.
* `use_github_release()` just creates the release.
* `use_version()` gains `push` argument.

Fixes #1385. Closes #1678.
jennybc added a commit that referenced this issue Mar 5, 2023
* Reduce number of manual release steps

* `use_release_issue()` checks default branch and pulls automatically.
* `use_github_release()` automatically pushes, if safe.
* `use_github_release()` just creates the release.
* `use_version()` gains `push` argument.

Fixes #1385. Closes #1678.

* Restore initial git pull

* Extract out git_push_first()

* Apply suggestions from code review

Co-authored-by: Jennifer (Jenny) Bryan <[email protected]>

* WS

* Re-document

* Tweak argument order

* Make some cli helper wrappers

* Don't mess with function order

* Update NEWS

* Tweak word

* Tweak comment

* Polish docs

* Don't mention release()

---------

Co-authored-by: Jennifer (Jenny) Bryan <[email protected]>
jennybc added a commit that referenced this issue Mar 10, 2023
jennybc added a commit that referenced this issue Mar 11, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature a feature request or enhancement git git, GitHub, and CI in general release 🛫
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants