Allow cross-repo pull requests to be opened

[patjakdev]

A common workflow for contributing to open source projects in Github consists of the following steps:

1. Create a fork of the repo that you intend to contribute to
2. Push a branch into your fork containing the changes you wish to merge upstream
3. Open a pull request in the upstream repo which references the branch in your fork

Right now, it doesn't appear that there's a way to push branches from git-spice into a fork and open a pull request in another repo. In particular, the RepositoryID of the CreatePullRequestInput that's passed to Github here is always the same as the repo where the branches are pushed.

I'm not sure what it would take to implement this feature. I suppose you'd need to add some config that specifies which repository PRs should be opened in and default it to the same as the one where branches will be pushed.

I'm willing to contribute myself if you'll point me in the right direction.

[patjakdev]

I see you have a similar problem in this project 🙂.

In my case, I do have permission to open PRs in the upstream repo, so I'd really like to be able to take advantage of the awesomeness that is git-spice for my contributions.

[abhinav]

Hey, @patjakdev.

Unfortunately, this is a limitation of stacking workflows with GitHub: you can only stack PRs on a repository that you can push branches to.

The workflow where you push a branch to a fork, and create a PR upstream only works if you have a single PR in the stack: the base branch is upstream:main, and the PR head is fork:feature1. As soon as you have >1 PRs, it doesn't work. E.g. PR 1 is upstream:main..fork:feature1, but PR 2 is fork:feature1..fork:feature2, so the second PR will be created on the fork itself. There's no way to work around this with GitHub; you can't say "upstream:feature1..fork:feature2" without being able to push a branch to upstream.

There are a couple workaround workflows:

• Use git-spice only to manage branches pushed to your fork without creating PRs (spice.submit.publish=false), manually open a PR upstream for the bottom-most PR in the stack, and when that lands, open a PR for the next one above it, and so on.
• Use git-spice to stack PRs against your fork and then create a PR upstream with the topmost branch in the fork. So, e.g. you have feat1->feat2->feat3 in your fork, and a PR to merge feat3 into main upstream. The message posted to the upstream PR can include a full view of the stack for ease of review.

I wouldn't be opposed to adding support to git-spice to open a PR to a different remote than where the branch was pushed, but I suspect it could cause confusion due to this limitation of GitHub. I'm open to ideas, though.

[patjakdev]

Fair points! I didn't understand this limitation in Github, but it does make sense now that you lay it out.

I wonder if git-spice could be augmented to support your first workaround workflow automatically. In other words, git-spice would do the work of making sure that there's a PR for the bottom-most branch and, when that PR is merged, automatically opening a new PR for the new bottom-most branch the next time I run gs stack submit.

That way, I could keep my workflow of curating a stack of branches locally and pushing them to my fork, but I'd let git-spice do the annoying work of creating the Github PRs and fixing up my local branches as PRs land upstream. In a dream world, git spice might even sync the default branch of my fork after it detects that PR upstream is merged.

Obviously, it would diverge from the normal workflows for stacked PRs but maybe this would be a "mode" you could put git-spice in for a particular repo via git config?

[abhinav]

I wonder if git-spice could be augmented to support your first workaround workflow automatically.

Yeah, that's a reasonable option. I thought about that too as I was writing out the first workaround workflow above. I'm going to put this in the planned features pile, but I can't make any promises on when I'll get to it.