You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When I review a PR I do not deal with the fork's branch name. Also when I check out a PR locally with:
hub pr checkout 123
I don't deal with the branch name and that is great. But this currently creates a branch, which is named after the fork's branch, which is also the first time I am seeing it. What is worse:
this branch can be in conflict with already existing branch, which I think then leads to Cannot use hub pr checkout after PR was updated #2448 (and any behavior discussed there for refreshing is even more dangerous - albeit I think it is needed) , especially with simple branch names like fix, typo or the GitHub autogenerated ones like patch
it makes orientation in the repo much harder, because of course not everyone keeps the same naming and sometimes (see above) the branch names are total garbage, this is problematic especially when you need to keep more PRs for longer time
after you check it out, you can no longer find it by the PR number, which is what you have been working with the whole time, what you you while referencing in other issues/PRs etc.
How I imagine hub could expose this functionality:
It would be much clearer if the branch names would be in format: pr-123. Even better would be pr-123-<branch-name> because then you can see what branches are PRs and you can find the branch both by the number or by the feature name.
I can of course provide my own name (hub pr checkout 123 pr-123), but it is more typing, I have to repeat the same twice plus I do not know the branch name so in case it is useful I am missing out on that.
This could also unlock some more functionality, because AFAIK currently after the branch is created the PR number is nowhere, so no other work can be done with the branch? Or am I missing something? If there was such a convention as I am proposing it would be similar as the current name upstream and its usage by the commands.
The text was updated successfully, but these errors were encountered:
@VasekPurchart Hi, does this sound like this which was suggested in the past? #1500
Also, are you aware that naming the local branch differently than on the remote means that you won't be able to push it back using git push without arguments with git default settings?
The problem I'm trying to solve:
When I review a PR I do not deal with the fork's branch name. Also when I check out a PR locally with:
I don't deal with the branch name and that is great. But this currently creates a branch, which is named after the fork's branch, which is also the first time I am seeing it. What is worse:
fix
,typo
or the GitHub autogenerated ones likepatch
How I imagine hub could expose this functionality:
It would be much clearer if the branch names would be in format:
pr-123
. Even better would bepr-123-<branch-name>
because then you can see what branches are PRs and you can find the branch both by the number or by the feature name.I can of course provide my own name (
hub pr checkout 123 pr-123
), but it is more typing, I have to repeat the same twice plus I do not know the branch name so in case it is useful I am missing out on that.This could also unlock some more functionality, because AFAIK currently after the branch is created the PR number is nowhere, so no other work can be done with the branch? Or am I missing something? If there was such a convention as I am proposing it would be similar as the current name
upstream
and its usage by the commands.The text was updated successfully, but these errors were encountered: