As far as I can see, when there is project metadata, the preview option
will never be shown in the interactive multiselect, so I don't believe
this change has any functional difference. However, I did use the
opportunity to drive out tests for generateCompareURL
Use PrRefs.GetPRHeadLabel() instead of headBranchLabel.
Also remove headBranchLabel from CreateContext struct.
To do this, we needed a new identifier for when the head repo should be
created via a new fork of the base repo. Previously, this was done by
checking if the head repo was nil, but if we want to call
GetPRHeadLabel(), it requires a non-nil head repo to construct the
headBranchLabel. So, instead of the head repo being nil to signal
a fork, we pass a new forkHeadRepo bool in the CreateContext struct.
This also makes the decision to fork more intentional; now the decision
is made clearly instead of if the headRepo happens to be nil.
Refactor pr create by reducing flapping `isPushEnabled` between true and false.
`isPushEnabled` is now also set to `true` by default, logically aligning with the
behavior description in the help text.
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.
This commit brings this code more into alignment with other places:
1. Using a local variable for upstream remote name instead of hardcoding everywhere
2. Raising error raised by setting default remote
3. Removing condition for displaying upstream default message
4. Bring message logic more inline with other places within function
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`
Latest Glamour has slightly changed logic in line length / wrapping,
resulting test failures due to string mismatch. Update tests and bump
dependency to v0.8.0, and others to the bare minimal level as generated
by `go mod tidy`.
This was detected then building the GitHub cli package `gh` in Debian
started to fail with src:golang-github-charmbracelet-glamour 0.8.0-1.
Closes: #10179
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
...
cmd.Output() will return an error when the git command ran successfully
but had no output. To handle this, we can check Stderr, as we expect it to
be populated for any ExitErrors or otherwise when there is a command
failure.
This allows for propagation of this error handling up the call chain, so
we are now returning errors if the call to git fails instead of just
handing off an empty BranchConfig and suppressing the errors.
Additionally, I've removed some more naked returns that I found in
pkg/cmd/pr/create.go createRun
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 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
