Open PR against gh-merge-base #9712

heaths · 2024-10-06T05:41:14Z

Partly resolves issue #8979 by checking for a gh-merge-base branch tag and using that as though it were passed to gh pr create --base.

heaths · 2024-10-06T05:43:06Z

I tested this against a repo I created with divergent main and feature/feat1 branches, and a task1 branch created from the latter with a manually set gh-merge-base: https://github.com/heaths/test-repo/pull/2

That said, we should probably wait to hear from @alexr00 or whoever manages the VSCode GitHub PR & Issues extension to possibly coordinate efforts. Or we could proceed and use those as fallbacks, but it seems a bit silly for the GitHub extension and the CLI to diverge.

williammartin · 2024-10-21T10:24:49Z

Hey @heaths, just filling in the communication gap here. This is on my radar but we're pretty busy in the lead up to universe next week. I expect it will be prioritised right after that.

williammartin

@heaths

Generally, I think this is very close. One question and one concern I'd like your input on.

Since this had been open for so long, and I wanted to make use of some testing utilities in trunk, I created #10004 since I didn't want to force push over your forked branch. I added some docs and a couple of acceptance tests. We're internally discussing what we want to do with this test suite that we started building for a different purpose, but I'm finding it useful to test some of these black box behaviours, and as demonstrations. Don't feel the need to add them yourself, they are just for the maintainers right now.

I don't feel that strongly about tying ourselves to what VSCode uses right now. Primarily my concern is that our teams are pretty distant, and I'm concerned about the increased cost of coordination. I'm happy to wait until people say they really want it to figure something out (maybe never?).

git/client.go

williammartin · 2024-12-04T11:35:18Z

pkg/cmd/issue/develop/develop.go


+	// Remember which branch to target when creating a PR.
+	if opts.BaseBranch != "" {
+		err = opts.GitClient.SetBranchConfig(ctx.Background(), branchName, git.MergeBaseConfig, opts.BaseBranch)


Concern

I'm a bit nervous about this purely because it's a breaking change.

Before this, development branches would always go back to the default branch unless otherwise specified with a flag. I don't have a clear answer for whether there are cases out there where people expect to create a development branch from a different branch than they want to PR back into.

Maybe we just bite the bullet and if someone complains, we can apologise. This definitely seems like the more natural default.

What do you think?

I appreciate it's a change, but seems it's a change for good. The CLI created the topic branch from the opts.BaseBranch in the couple of code blocks above. If it were to target the default branch, the commit graph could be a real mess: the base branch may not be merged or, worse, has diverged from its base branch entirely e.g., a hotfix or feature branch, or just a branch for stabilization aka "release branch".

But, yes, it is a change. What if, as compensation for trying to do the, IMO, right thing here, interactive prompts to create a PR ask for the base (merge) branch with the current (or default) as the default value if they just hit Enter?

I don't think that we would target the default branch explicitly, just not set gh-merge-base at all, leaving the behaviour as-is. That said, I'm inclined to bite the bullet on this one. It makes sense to me that the default is to target the branch that we used as a base.

If we hear complaints then we can change it back and perhaps introduce a config setting for permanently chjoosing what to do.

What if, as compensation for trying to do the, IMO, right thing here, interactive prompts to create a PR ask for the base (merge) branch with the current (or default) as the default value if they just hit Enter?

I think that makes sense to me. Mostly this is going to be an issue in the interactive case because it's part of gh issue develop which is almost always going to involve a human at the keyboard.

williammartin · 2024-12-04T18:58:06Z

If we address the pr create prompt, and bring in the changes from my PR, I think this is good to go. Thanks.

Partly resolves issue cli#8979 by checking for a `gh-merge-base` branch tag and using that as though it were passed to `gh pr create --base`.

heaths · 2024-12-09T01:46:54Z

I rebased and cherry-picked your changes, sans an errant whitespace issue and a couple of grammatical fixes. I'll try to get to the gh pr create interactive change yet tonight.

@williammartin

Merges changes from @williammartin including acceptance tests and word changes. Co-authored-by: William Martin <[email protected]>

If interactive, confirm the automatically configured gh-merge-branch or, if not configured, the default branch. Based on PR feedback.

heaths

@williammartin I implemented the prompt, did some manual tests, and added a prompt test. Unfortunately - though practical - the initial message about creating the PR from the topic branch to the base branch is based on the configured branch. I added a comment to that effect.

This reverts commit e021a07.

williammartin

Thanks for doing the prompting on PR create. I played around with it myself and decided that:

I didn't like the prompt appearing under the normal flow today (i.e. when there is no gh-merge-base config), because it's adding an extra hop that is probably unchanged 99% of the time)
Didn't like that the prompting would diverge between having gh-merge-base configured, and not.
Didn't like the extra hop that would be required of everyone using gh-merge-base.
Didn't think that after maybe some initial annoyance, that it provided that much more value over the current text that mentions the branch explicitly:

Creating pull request for williammartin:merge-base-pr into feature in williammartin-test-org/williammartin-test-org-test-repo-rename

Didn't like that this static text could later be incorrect on scrollback because it was later changed via interactivity.

So all those things considered, I decided to revert the last commit, hope that makes sense. Sorry for the extra work.

pkg/cmd/pr/create/create.go

heaths · 2024-12-09T15:45:50Z

I see you already merged it, but I woke this morning - after going to bed with an uneasy feeling I couldn't quite place about this - thinking that this prompt changes the flow quite a bit. It's always going to prompt unless you pass --base, so should we maybe instead prompt to set the gh-merge-base when running gh issue develop, or finish the implementation and decide then?

williammartin · 2024-12-09T15:57:22Z

so should we maybe instead prompt to set the gh-merge-base when running gh issue develop, or finish the implementation and decide then?

Hmm, really not sure. Prompting could be good, but I think it only makes sense if we also introduce a flag to avoid it in the non-interactive flow. I don't really like the lack of consistency having an option one way and not the other.

or finish the implementation and decide then?

What implementation do you still have in mind? I know in the issue we talked about following the reflog algorithm, presumably on pr create with a new flag? How much extra value does this provide to you over the feature delivered here?

heaths · 2024-12-09T18:08:55Z

What implementation do you still have in mind? I know in the issue we talked about following the reflog algorithm, presumably on pr create with a new flag? How much extra value does this provide to you over the feature delivered here?

I never use the gh issue develop. I suspect a lot don't. I always git checkout -b {new-branch} ({optional head e.g., FETCH_HEAD}) and then later gh pr create. We discussed above about the automatic resolution, which I'd like to finish.

I still think this needs to be in the GraphQL to find the closest ancestor known to GitHub in the upstream repo. What you have locally doesn't really matter. As long-time user of git, I often have various local branches I use for prototyping or if I want to try a couple different approaches so I can easily pick one.

Follow-up to PR cli#9712

This MR contains the following updates: | Package | Update | Change | |---|---|---| | [cli/cli](https://github.com/cli/cli) | minor | `v2.63.2` -> `v2.64.0` | MR created with the help of [el-capitano/tools/renovate-bot](https://gitlab.com/el-capitano/tools/renovate-bot). **Proposed changes to behavior should be submitted there as MRs.** --- ### Release Notes <details> <summary>cli/cli (cli/cli)</summary> ### [`v2.64.0`](https://github.com/cli/cli/releases/tag/v2.64.0): GitHub CLI 2.64.0 [Compare Source](cli/cli@v2.63.2...v2.64.0) #### What's Changed - docs: improve docs for browse command as of [#5352](cli/cli#5352) by [@ankddev](https://github.com/ankddev) in cli/cli#10025 - Open MR against gh-merge-base by [@heaths](https://github.com/heaths) in cli/cli#9712 - Add integration tests for `gh attestation verify` when the `bundle-from-oci` flag is specified by [@malancas](https://github.com/malancas) in cli/cli#10020 - `gh repo rename` help text clarifies new repo name should not include owner by [@BagToad](https://github.com/BagToad) in cli/cli#10044 - fix: list branches in square brackets in `gh run` and `gh codespace` by [@uday-rana](https://github.com/uday-rana) in cli/cli#10043 - Bump actions/attest-build-provenance from 1.4.4 to 2.1.0 by [@dependabot](https://github.com/dependabot) in cli/cli#10056 - Bump golang.org/x/crypto from 0.29.0 to 0.31.0 by [@dependabot](https://github.com/dependabot) in cli/cli#10070 - Improve documentation and error messaging for local extension installations without executables by [@BagToad](https://github.com/BagToad) in cli/cli#9933 - docs: better document auth scopes by [@ankddev](https://github.com/ankddev) in cli/cli#10026 - Sigstore verifier logic updates by [@malancas](https://github.com/malancas) in cli/cli#9999 - `gh pr merge --delete-branch` exits with error when merge requested via merge queue by [@BagToad](https://github.com/BagToad) in cli/cli#10074 - sundry `gh at inspect` improvements by [@phillmv](https://github.com/phillmv) in cli/cli#9954 - Support `pr view` for intra-org forks by [@williammartin](https://github.com/williammartin) in cli/cli#10078 - Print policy information before verifying attestations by [@malancas](https://github.com/malancas) in cli/cli#9891 - Improve error handling in apt setup script by [@jobegrabber](https://github.com/jobegrabber) in cli/cli#10055 - Use Windows compatible file name for downloaded attestations when running `gh attestation download` by [@malancas](https://github.com/malancas) in cli/cli#10051 - Bump github.com/cpuguy83/go-md2man/v2 from 2.0.5 to 2.0.6 by [@dependabot](https://github.com/dependabot) in cli/cli#10094 - Perform all `gh attestation verify` policy options configuration in the `newEnforcementCriteria()` function by [@malancas](https://github.com/malancas) in cli/cli#10012 #### New Contributors - [@ankddev](https://github.com/ankddev) made their first contribution in cli/cli#10025 - [@uday-rana](https://github.com/uday-rana) made their first contribution in cli/cli#10043 - [@jobegrabber](https://github.com/jobegrabber) made their first contribution in cli/cli#10055 **Full Changelog**: cli/cli@v2.63.2...v2.64.0 </details> --- ### Configuration 📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever MR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this MR and you won't be reminded about this update again. --- - [ ] If you want to rebase/retry this MR, check this box --- This MR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).

heaths · 2025-04-25T16:41:58Z

@jtmcg was surprised this wasn't mentioned in https://github.blog/open-source/git/how-the-github-cli-can-now-enable-triangular-workflows/, or is this too specific of a workflow i.e., targeting feature branches? I know we're definitely not unique in that, but a "hero scenario" it is not.

That said, the blog post reminded me that the complete E2E solution for #8979 hasn't been finalized. Are we still going to automatically set the gh-merge-base a la VSCode/GitHub Issues and Pull Request?

Follow-up to PR cli#9712

heaths requested a review from a team as a code owner October 6, 2024 05:41

heaths requested a review from williammartin October 6, 2024 05:41

cliAutomation added the external pull request originating outside of the CLI core team label Oct 6, 2024

williammartin mentioned this pull request Dec 4, 2024

Support gh-merge-base on pr create and set during issue develop #10004

Closed

williammartin reviewed Dec 4, 2024

View reviewed changes

heaths added 2 commits December 8, 2024 17:40

Open PR against gh-merge-base

3d13901

Partly resolves issue cli#8979 by checking for a `gh-merge-base` branch tag and using that as though it were passed to `gh pr create --base`.

Set gh-merge-base from issue develop

88b96f4

heaths force-pushed the issue8979 branch from 461441a to 88b96f4 Compare December 9, 2024 01:46

Merge changes from cli#10004

5da86e0

Merges changes from @williammartin including acceptance tests and word changes. Co-authored-by: William Martin <[email protected]>

heaths force-pushed the issue8979 branch from 102dd82 to 5da86e0 Compare December 9, 2024 04:34

Confirm auto-detected base branch

e021a07

If interactive, confirm the automatically configured gh-merge-branch or, if not configured, the default branch. Based on PR feedback.

heaths commented Dec 9, 2024

View reviewed changes

Revert "Confirm auto-detected base branch"

54a7f4d

This reverts commit e021a07.

williammartin approved these changes Dec 9, 2024

View reviewed changes

pkg/cmd/pr/create/create.go Outdated Show resolved Hide resolved

williammartin merged commit 46bba45 into cli:trunk Dec 9, 2024

heaths deleted the issue8979 branch December 9, 2024 15:44

This was referenced Dec 16, 2024

pr create should use gh-merge-base git branch config when determining base branch #10088

Closed

issue develop --base should result in pr create using that branch as the base later #10089

Closed

heaths mentioned this pull request Dec 20, 2024

Document how to set gh-merge-base #10112

Merged

heaths added a commit to heaths/cli that referenced this pull request Dec 20, 2024

Document how to set gh-merge-base

7883609

Follow-up to PR cli#9712

jtmcg mentioned this pull request Jan 27, 2025

Find PRs using @{push} #9208

Merged

rancorm pushed a commit to rancorm/cli that referenced this pull request May 3, 2025

Document how to set gh-merge-base

3b7a9ba

Follow-up to PR cli#9712

Uh oh!

Open PR against gh-merge-base #9712

Open PR against gh-merge-base #9712

Uh oh!

Conversation

heaths commented Oct 6, 2024

Uh oh!

heaths commented Oct 6, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

williammartin commented Oct 21, 2024

Uh oh!

williammartin left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

williammartin Dec 4, 2024

Choose a reason for hiding this comment

Uh oh!

heaths Dec 4, 2024

Choose a reason for hiding this comment

Uh oh!

williammartin Dec 4, 2024

Choose a reason for hiding this comment

Uh oh!

williammartin commented Dec 4, 2024

Uh oh!

heaths commented Dec 9, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

heaths left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

williammartin left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

heaths commented Dec 9, 2024

Uh oh!

williammartin commented Dec 9, 2024

Uh oh!

heaths commented Dec 9, 2024

Uh oh!

heaths commented Apr 25, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

heaths commented Oct 6, 2024 •

edited

Loading

heaths commented Dec 9, 2024 •

edited

Loading

heaths left a comment •

edited

Loading

williammartin left a comment •

edited

Loading