facebook
`sl pr submit` picking upstream over fork is unexpected and not desired
I made the mistake of sending a massive number of pull requests to the neovim repository, thinking that sl pr submit --stack would use my fork. I then read through the documentation to realize that it prefers the upstream repository in the case where default or default-push are a fork, which is not the behavior I'd expect.
It's not clear to me how to control this behavior other than not using a forked repository and instead manually cloning the repository using git and pushing to my own version without the fork. As the upstream repository does not want multiple pull requests due to the load on the CI, I was planning to have a dialog on my fork and merge all of the work into a single PR down the line.
Is there any guidance on how to get Sapling's pr submit to go to a fork?
Just made the same embarrassing mistake. Looking for a way to continuously rebase a personal fork on top of a remote upstream.
Hmm, yeah - this is not what you want when you are developing in the fork.
We could add an --upstream flag to "pr submit" to make it explicit. We could also prompt the user on their first submission to learn their preferred default value. Thoughts?
@muirdm I can't speak to how most people would use the tool, but I personally would expect the default behavior to submit to the origin (my fork) with the --upstream flag to submit to the upstream repo like you're suggesting.
Git prompts you to specify your merge preferences when first merging, so prompting a user on their first submission, defaulting to the origin (fork, in this case), seems like the best approach to me.