Andreas Enge <[email protected]> writes: > This is another question I had, which is not necessarily related to > next-master. Maybe people should all the time declare their pull > requests as relative to master? There is this annoyance of a team > branch that once it is merged and deleted causes all other pull requests > to this branch to be closed. Since anyway we do not merge with the push > of a button, but committers effectively cherry-pick the single commits, > are we not already in this patch based workflow?
Committers should be ready for that. What about Codeberg/the contributers though? When you want to contribute to a team branch, you have two options: 1. Target team branch 2. Target master branch If you choose 1, it's very simple, you just locally use the team branch, do your work on it, commit it, test it, submit it as PR against team branch. If you choose 2, you are going to struggle. If you decide to start from the team branch for simplicity, submit it to Codeberg, Codeberg will show you a ton of new commits as part of that PR. Its UI will be very hard to read. This will ping a lot of people at least now due to the automatic process of adding review requests. You could do: 1. do your work on top of team branch 2. test it 3. cherry pick the commit on top of master 4. submit PR against master but this is unintuitive and complicated. Moreover it can lead to conflicts in case your change touches something that's already touched on the team branch, making it more work for both the committer and contributor. Second option is starting from master, but this way you cannot test your change. I think if we wanted contributers to follow these steps, we're making it maybe even more complicated than what was the initial patch process. One of the reasons from moving away from it was user experience for new contributors. Also with this approach you would be giving up refs/pull. The problem here is that Codeberg itself is not patch oriented, it doesn't understand patches, it looks at 'shared' histories of the branch and the PR and treats that as a difference to show you in all the comparisons. Maybe the tooling that hako has set up on their account could be adapted to understand patches more, but still Codeberg UI will give confusing signals. Or am I overseeing something? > branch that once it is merged and deleted causes all other pull requests > to this branch to be closed. IMO this warrants reconsidering the policy rather than telling contributors to use more complicated ways. If the argument is that branches are removed to show that they have been merged, I think that can be solved by a simple script that will check if HEAD of that branch is already in master. Regards Rutherther
