[Mesa-dev] Gitlab migration
nhaehnle at gmail.com
Thu May 24 08:59:33 UTC 2018
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
>>>>> and switching to that may lower the barrier to entry for new
>>>> 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
>>>> history and/or squashing everything on the final commit, and that's
>>>> 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
>>> 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
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
More information about the mesa-dev