Sprint notes for gitlab discussion

[Vlad Zahorodnii]

Hi,

On 6/15/20 1:06 AM, David Edmundson wrote:
>   - There was a discussion on the two different styles of use gitlab 
> use. Some people squash locally and have a nice neat commit history. 
> Others don't, and then just squash at end.
> 
>       - Conclusion was it's unreasonable to get devs to squash and 
> rebase "nicely" as it's perceived as too hard (even though it really 
> isn't - ed)

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.

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

    A -> B

a code reviewer spots an issue and asks the author of the merge request 
to address it

    A -> B -> C' (C' is the commit that fixes the issue)

another code reviewer shows up and notices another problem

   A -> B -> C' -> D'

after a couple of more code review rounds, we end up with the following 
commit history

   A -> B -> C' -> D' -> E' -> ... -> Approved'

The question is: how commits C', D' and so on are going to be squashed? 
What if some of those commits cannot be squashed cleanly because of 
merge conflicts? Will resolved merge conflicts go in unreviewed?

I agree that the interactive rebase tool is difficult to master, but we 
could provide an example of recommended gitlab workflow on our wiki and 
point newcomers to it. By doing so, we will help the newcomers grow 
professionally and hopefully give them a reason to continue contributing 
to KDE. :-)

Cheers,
vlad