Comment by rawling
1 day ago
I've just been shunted from TFS Git (Azure DevOps?) to GitHub.
The PR UI is taking some getting used to.
Dev changes code near a comment I made? Comment is marked "Outdated" and hidden. If I open it, can I see what change they made next to the comment? Nope, I have to go find it manually!
It sorts X.Y below X.Y.A, X.Y.B etc. in the file listing.
When I select a file in the listing I'd like to just have that file open, not scroll to it in a list of all the changes.
The first PR I did showed a ton of changes that had already been merged from common history. I can see the merge commit you made, GitHub, I know you know none of these changes are actually being made.
Not caring if a required action hasn't run automatically. No "run" option, not even a "this isn't ever going to run", just "waiting for result".
Weirdly, showing the result of an action on the source branch, when it needs to pass on the merge commit.
I've not yet figured out how to require different approvers for different branches, although that one might be on my org settings. It's either the people in the codeowners file or any contributor?
No way to allow a ruleset to be bypassable while making the approvers still manually bypass it themselves. I want to know if I'm getting it wrong as much as I want to stop my junior devs messing up.
Finding conflicts in a PR between two branches that can merge cleanly if I do it locally.
Not letting you resolve conflicts in the UI if the source branch is protected, even though the UI gives you the option to commit the resolution to a new branch if you do it for an unprotected source branch.
Updating the source branch in the PR if you choose to do the above - something you can't do yourself!
Not showing branches in a hierarchy (as if they were directory paths)