Merging PRs through GH
zacanger opened this issue · comments
Is this a feature request or a bug?
Request
Expected behavior:
When a change is merged, the notifications should indicate that it was merged
Actual behavior:
Because GH notifications around merged changes are based around how the patches landed, contributors see a glaring red icon and notification showing their pull requests were closed.
Steps to replicate:
This is kind of a weird issue, but could maybe affect future contributions. GH PR notifications show up differently if the PR was merged vs if commits were cherry picked or merged manually followed by closing the PR. I don't think anyone who has contributed so far has had an issue with that, just wanted to point it out, because the way GH notifies folks differs.
If a PR is merged through GH, the web notification at least (I turned off email notifications ages ago) will let them know their changes were merged. If their change was manually merged and pushed to the base branch, or if their commits were cherry-picked — either way — if their PR was closed without merging, the notification implies that their change was rejected.
To be clear, this is probably a GH limitation, and is purely about the UX of contributing, but could potentially turn off new contributors or contributors who aren't super familiar with Git, so I just wanted to point it out and ask if maybe merging PRs through GH might be an option.
Environment info (where relevant)
N/A
- Browser:
- Operating System & Version:
- Version of Node (
node -v): - Version of ds (
ds --version):
related question. how we should merge PRs which contains multiple commits? I used to workflow where internal commits of PR don't matter because you do squash and only single commit goes in master.
It looks like not the case for entropic. So shell author clean up history in PR and make only 1, 2 commits?
@zacanger I believe we aren't using the github merge button so we can do more without direct author input -- it allows us to do minor things (or combine multiple related concepts that might build off each other) to the commit before it's placed into master.
as the cadence gets better and more contributors (on the code level) are introduced, this will likely change
@fetis frequently people will use the squash and merge button so the branch is a single atomic commit
Mea culpa! I switched over to merging manually using cherry-pick and amend. I did this mostly because:
- As @toddself notes, it's handy to be able to fixup commits before landing them. I'm usually doing commit style (standard release) tuning and adding a
Fixes #<PR Number>message. Sometimes I'll have to do some more involved work to get things to land. - This also forces me to do the rebase manually, make sure it applies cleanly, and make sure the system works on the other end.
I had been trying to comment Thanks! Rebased and merged in <commit> on the closed PRs but I got a bit lax about that, apologies!
This is kind of a stripped down version of Node's "landing a pull request" guidelines.
I like to preserve commits where I can, but we're presently pretty lax about commit discipline here. We're lazily adhering to conventional commits where possible, but not worrying about it too much where we lapse. This is appropriate given the state the project is in right now, I think. The goals that commit discipline exists to support are:
- To make building a CHANGELOG as easy as we can in the future (note: we haven't done this yet!)
- To make tracking down the source of bugs easy in the future (right now they're all very shallow bugs)
- To make backporting easier to support earlier releases (right now we only have one release line: tip of tree)
Notably: we're not doing any of these things (yet!) – I suspect when we start doing any one of them we'll want to tighten up our commit discipline. I've been starting to fixup commits to conventional commit standard opportunistically – the problem I've been directly trying to solve is landing commits that break the master branch when merged/rebased.
As we add maintainers and start taking on those commit discipline goals we'll gradually tune the commit policy (& document it ahead of time!) For now contributors shouldn't worry about strict adherence outside of the usual git hygiene: cut commits however you feel best communicates the purpose of the work contained. I (or Ceej) will reformat to match conventions on merge.
Thanks for explaining! I'm going to close this. Didn't want to imply any pressure to change the process, just point out the potentially weird experience for new contributors. Since this issue will hang around, your comment might be a useful link if someone brings it up again.