Consider this work flow:
hub pr checkout 123
hub pr checkout 123
againAt this point, since I already had the branch checked out, hub
tries to fast forward my branch. This fails because there are conflicts.
I would love to have a flag like --force
or --recreate-branch
that deletes and recreates the branch for me. Since I am only reviewing the patch, there is no harm in deleting the branch.
$ hub version
git version 2.14.1
hub version 2.10.0
One idea here is to introduce a new command: hub pr tmp-checkout
. This would always create a branch with a temp prefix (or some other identifier) so that hub
knows that it's safe to delete and recreate the branch.
Thanks for writing in! I'm leaning to having hub pr checkout
always reset the branch to the current state of PR head branch, regardless of whether it was a fast-forward or not. That would enable you to practice this workflow without passing any extra arguments. However, if you yourself had added local commits to the branch and then checked out Janice's work, your local commits would be "lost". Could this be a potential issue?
My 2 cents.
I think that should be implemented the choice for replacing or not the old copy of the PR.
The reason for this is that sometimes I'm interested in checking only the differences that were force pushed and maintaining the old copy allows me to do it.
However, if you yourself had added local commits to the branch and then checked out Janice's work, your local commits would be "lost". Could this be a potential issue?
Yeah, the commits would be lost (or very hard to find). It would be surprising if something like hub pr checkout ...
could destroy existing history. I'd be less surprised if something named hub pr tmp-checkout
destroyed history.
I've been using hub pr checkout...
for my own branches a lot lately. It's easier than typing the branch name 馃槃 Because of this, I think it would be better to introduce a new command such as tmp-checkout
to implement a truly temporary, self-destructable checkout feature.
A force flag as in hub pr checkout --force
would make the overwrite explicit without introducing a new command, and mirrors the git push --force
command that has been used to update the branch.
Most helpful comment
Thanks for writing in! I'm leaning to having
hub pr checkout
always reset the branch to the current state of PR head branch, regardless of whether it was a fast-forward or not. That would enable you to practice this workflow without passing any extra arguments. However, if you yourself had added local commits to the branch and then checked out Janice's work, your local commits would be "lost". Could this be a potential issue?