Sprint notes for gitlab discussion

[David Edmundson]

So to clarify, there are two allowed gitlab workflows.

MRs for chains of nicely done rebased commits
MRs where one MR represents a single logical commit to be squashed and the
list of actual commits uploaded is garbage.


>
> One issue with such a workflow is that code reviewers will have to
> accumulate all commits in their mind. Speaking for myself, that is
> really difficult.
>

Not really, we either just either review individual commits, or we review
the whole merge request depending on what is relevant from the style used.
It's normally clear from the commit names.


> Another issue is that it's not clear how the commits are going to be
> squashed, which makes it even more hard to add "ship it."
>



> For example, let's consider that a person has created a merge request
> with two commits
>

If the person is good at git, they'll squash C locally before force pushing.
If the person is not, they should just have made two merge requests to
begin with.

I think we can certainly encourage the good git pattern especially for an
advanced complicated multi-commit branch.
it's just a case of finding a balance for the people just doing really
simple changes.

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20200615/1c3f702c/attachment-0001.htm>