This commit converts all of the places using ColorScheme.Gray and ColorScheme.Grayf to Muted and Mutedf.
There is a little extra tidying up with local variable names or converting code to use Mutedf format.
There is still a bit of work to get the gh pr comment tests in order, however this goes a way towards fixing the issue along with acceptance tests.
Also, it turns out some of the issue acceptance tests were really running `pr` tests.
Due to the refactor of BranchConfig, the tests for `pr create` no longer
require a handful of stubbed git commands.
Additionally, I noticed some overlap between `pr create`'s existing logic
with the new finder code. I suspect that the finder's new ParsePRRefs
helper could be leveraged here as well, which would allow us to respect
non-centralized workflows pr create in the same way we are respecting them
in `gh pr view` and `gh pr status`
There was a lot of copy-pasta code between the finder and pr status. After
some investigation it was clear that the prSelectorForCurrentBranch code
was really just a duplicate of the finder's code without actually making
the API call for the PR. Since the ParsePRRefs helper had already
extracted much of the logic for determining a PR's head ref branch, I was
able to reuse it in gh pr status with a small refactor.
I've been struggling horribly to reason through all of this code, and
after much mental gymnastics I identified the culprit as the overloaded
"branch" string returned by parseCurrentBranch.
This value was either the name of the branch that the PR we're looking for
is associated with, or that name prepended with the owner's name and a :
if we're on a branch, so:
PR branch: featureBranch
branch == "featureBranch"
If on Fork belonging to "ForkOwner"
branch == "ForkOwner:featureBranch"
Since this extra information was bundled up into this single string, it
complicated the responsibilities of parseCurrentBranch's "branch" return
value. Thus, I've teased out "branch" into the new PRRefs struct:
type PRRefs struct{
BranchName string
HeadRepo ghrepo.Interface
BaseRepo ghrepo.Interface
}
This allows the new parsePRRefs function to move all the previous
"branch" string's information into structured data, and allows for a new
method on PRRefs, GetPRLabel(), to create the string that "branch"
previously held to pass into its downstream consumer, namely
findForBranch.
This also allowed for better test coverage, directly connecting the PRRefs
fields to the values contained in the git config. Overall, I am now
confident that this is doing what its supposed to do with respect to my
understanding of the various central and triangular git workflows we are
addressing.
A recent refactor caused the API for ReadBranchConfig to change, resulting
in changes for its consumers. Additionally, there was a large refactor of
the tests associated with ReadBranchConfig and its consumers to gain
confidence in this refactor. This commit attempts to resolve the
conflicts between the refactor and this effort as well as massage the
changes introduced here to reflect the refactor.
The refactor PR can be found here: https://github.com/cli/cli/pull/10197
I'll note that there are still a few failing tests in status_test.go. I
haven't had a chance to fully grok while they are failing, yet, and
suspect that some insights from the original PR author may be helpful
here.
Full disclaimer: I haven't verified any of this is working locally yet.
My primary motivation is to get these new changes working together in a
manner that unblocks further iteration on this effort.
* trunk: (79 commits)
Enhance help docs on ext upgrade notices
chore: fix some function names in comment
Expand docs on cleaning extension update dir
Simplifying cleanExtensionUpdateDir logic
Separate logic for checking updates
Capture greater detail on updaterEnabled
Restore old error functionality of prSelectorForCurrentBranch
Change error handling on ReadBranchConfig to respect git Exit Codes
fix: add back colon that I removed
fix: actually read how MaxFunc work and simplify the code
fix: padded display
Collapse dryrun checks in ext bin upgrade
Bump github.com/mattn/go-colorable from 0.1.13 to 0.1.14
Rename test user in tests
Change pr number in test
Surface and handle error from ReadBranchConfig in parseCurrentBranch
Directly stub headBranchConfig in Test_tryDetermineTrackingRef
Refactor error handling in ReadBranchConfig to avoid panic
Refine error handling of ReadBranchConfig
Add test for empty BranchConfig in prSelectorForCurrentBranch
...
I've only added the one test for parseCurrentBranch because the function
appears to be largely exercised by TestFind. There's definitely an
opportunity for a bigger refactor of the tests, here, but I want to avoid
scope creep as I propagate the ReadBranchConfig api changes throughout the
codebase
When using a push.default = current triangular workflow, apart from
using @{push} to determine the remote branch name, we should also follow
the
1. branch.<name>.pushRemote
2. remote.pushDefault
3. branch.<name>.remote
...list to determine which remote Git pushes to.
When push.default is not 'upstream' / 'tracking' (or 'nothing'), we can
expect local and remote branch names to be the same and solely rely on
@{push} or RemoteURL.
This fixes the wrong error message 'no pull requests found for branch
"<target branch>"' when the local branch is not pushed in the
push.default = simple / current and upstream = <target branch> setup.
When using a push.default = current central workflow [1], we should use
@{push} instead to locate the remote branch.
In fact, @{push} covers most cases in push.default = upstream too. The
branch.<name>.merge is probably only needed when using RemoteURL and
different remote / local branch names.
[1] https://github.com/tpope/vim-fugitive/issues/1172#issuecomment-522301607
This commit reverts the previous color changes in the prompt UI. While color highlighting could potentially improve the visual appealing of the prompt
using the existing color library (mguz/ansi) with the prompt library (AlecAivazis/survey) caused unintended side effects.
It reset the bold text style for the selected option. We decide to that
bold text style would have a higher priority than the color text ,for
three reasons:
1. To maintain consistency with other prompts in the UI and prioritize accessibility
2. While color can enhance the user experience, according to Primer Design Guidelines, color should not be relied upon to convey essential information.
3. visual indicator of the selected option, especially crucial when dealing with long PR titles or branch names.
As a future improvement, we may consider a separate issue or PR to address the color library issue and explore controlled color usage in prompts. This could potentially allow for more nuanced visual differentiation while avoiding unintended style resets.
Co-authored-by: Kynan Ware <47394200+BagToad@users.noreply.github.com>
Improve the interactive PR selection UI by
- prefix the PR number with hashcode #
- perserve the text formatting (bold) upon an option is hovered
- add the PR head label
Technical changes:
- Replace \033[0m with \033[39m for maintaining text formatting
Currently, the prompter doesn't enforce the requirement of a title for PR
and Issue creation. However, that creates the UX where a user can enter a
blank title, spend time filling out a detailed body, then fail to create
the issue or pr when the request is sent to the api because the title is
blank. This attempts to handle that before sending a request to the api,
enforcing that, when prompting, the title of an issue is not blank.
