[Mesa-dev] Gitlab migration

[Nicolai Hähnle]

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.