What happens when someone pushes an update to your PR branch?

[pokey]

The guide in https://getcord.github.io/spr/user/patch.html describes what happens if you want to edit someone else's PR, but it doesn't say how the other person should get the new changes. Have I missed that somewhere in the docs?

Thanks!

[sven-of-cord]

This is not meant to be a collaborative work-on-PRs-together feature, but rather an escape hatch (e.g. PR author is on leave but you need to fix and land the PR). As stated in the docs, doing this overwrites the state of the PR. The original author could use spr patch again to have a local branch that contains the current state of the PR. But in the context of stacked PRs there would be some local git work to be done to integrate it into the local branch. Don't work collaboratively on single PRs! It runs counter to the premise of the diff style workflow. Instead make smaller PRs. Land early, land often. Use config flags or feature gates to land implementation steps of features you don't want to be public yet (e.g. because they are not fully implemented yet). Don't have long-lived branches.

[pokey]

Yeah interesting philosophical pushback. I think that is probably reasonable for the PRs that I put up, but as a full-time open source maintainer, I frequently have to edit other people's PRs. I guess for those situations, though, it probably makes sense to just not use spr at all, and just add commits to the tip of their PR branch like I usually do. This was something I avoided when I worked at a tech company, but is the only way I know to make progress as an open-source maintainer, given the sparse attention of open-source contributors

Btw on an unrelated note, while I have your attention, I'll point you at https://github.com/arxanas/git-branchless/discussions/45#discussioncomment-3698369. Would love to hear your thoughts in that discussion thread on if / how the two tools should interact

[sven-of-cord]

Yes, that's an interesting point.

spr is an opinionated tool that was built to facilitate a very specific workflow. As much as I like that workflow, I can see there are situations where it's not ideal. My daily work is in a company in a team of full-time employees. The Phabricator-style workflow spr tries to imitate as well as possible works great for us. Open source development is very different though.

spr abstracts away the fact that PRs are branches. For OSS, you may not want that, and rather work with branches. I can see that.

Point in case: this repository. I use spr to submit code that my colleagues can review. But external contributors can't. Not really.

I will have a look at that issue you link to in a moment...

[pokey]

Yep makes sense. Feel free to close, or leave open if this is something you think you might tackle in the future