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
