On 24.05.2018 08:46, Tapani Pälli wrote:
* [Optional] Merge-request workflow. With the rise of github, there
are many developers out there who are used to the merge-request
workflow
and switching to that may lower the barrier to entry for new
contributors.
I admit that it's been a while since I checked, but the web-based merge
workflows of GitHub and GitLab were (and probably still are) atrocious,
so please don't.
The tl;dr is that they nudge people towards not cleaning up their
commit
history and/or squashing everything on the final commit, and that's
just
a fundamentally bad idea.
The one web-based review interface I know of which gets this right is
Gerrit, since it emphasizes commits over merges and has pretty good
support for commit series.
One really nice thing is that it actually has a view of outstanding
patch series, that's properly tied to things getting committed, unlike
patchwork which is only useful if people bother to curate their series'
status. I'm struggling to keep up with mesa-dev these days, despite it
being my day job. Having a page with the series outstanding might make
life easier for reviewers, and also make it easier for series not to get
lost and fall through the cracks...
I agree that that's useful. As well as the automatic tracking of what
got merged.
Mechanically, it also had pretty reasonable support for multiple patch
series, updating a previous one automatically (IIRC).
One thing I hated about using Gitlab for the CTS is that every series
created merges, littering the history...and worse, people got in the
habit of only explaining their work in the pull request, which became
the merge commit message. People didn't bother giving individual
commits meaningful explanations. That made 'git blame' harder, as
you had to blame then look for the merge...makes bisects messier too...
That's the thing that really worries me. I always got the impression
that the UI emphasizes merges over commits, and that is the real problem
precisely for the reasons you explain.
There is a per-repo setting for what kind of merge requests are
allowed and one option is to only allow fast-forward merges. I think
there's also an option to automatically rebase the branch prior to
merging. That doesn't enforce good commit messages but it does kill
the merge commits.
It's possible to also just decide not use the 'merge button'. Within
Android-IA scope it was decided to manually push commits and just close
pull requests when pushing to keep git history clean.
I'm actually fairly mellow on both the merge vs. fast-forward and 'merge
button' points. The real issue is keeping git blame, bisect, and commit
messages meaningful.
Cheers,
Nicolai
--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
