pr_forget()

[hadley]

We need some function to terminate a pr (without merging it) if you decide that fetching or creating it was a bad idea. Currently, I do git checkout master then git branch -D <branch>, but that doesn't remove any remotes that might've been added. I don't think this would touch remote branches.

[jtr13]

Yes, this would be super helpful. My use case is examining student PRs and telling them what to fix. What I'm doing now (with help from ROpenSci slack) while on the PR branch to jump ship is:

$ git reset --hard [<commit>] (include PR branch <commit> if I've made commits)
$ git clean [-d] -f (include -d to delete new subdirectories)

> pr_finish()

[jennybc]

I think it's fair to say that what we want from pr_forget() is to return one's local Git state to where it was before we did pr_fetch(), yeah?

[hadley]

Yeah, exactly.

[jennybc]

Note to self: also handle the case where the whole thing started with pr_init()

[jennybc]

@hadley Are these all the ways in which pr_forget() is not just pr_finish()? I've updated pr_finish() and I want to understand how they differ.

For pr_forget():

• The target branch need not have been pushed and made into a PR (pr_finish() stops if there's no associated PR)
• It always involves a local branch, i.e. it's never a remote-only operation (pr_finish() can now delete the remote branch associated with a merged PR, even if we never fetched it)
• We never delete a remote branch (pr_finish() will do so, under certain circumstances)
• We do not fret about commits that only exist locally (pr_finish() informs the user about such commits and asks if they want to proceed)

[hadley]

I was just thinking about the last bullet this weekend — I think it probably needs to warn that you have work that won't be pushed, and require confirmation to continue. Otherwise, that sounds correct to me.