<div dir="ltr"><div dir="auto"><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><a href="https://community.kde.org/Infrastructure/GitLab#Curating_your_merge_request_commit_history" rel="noreferrer noreferrer" target="_blank">your_merge_request_commit_history</a>.<br>
<br>
However, it remains a fairly advanced workflow which is challenging for <br>
newcomers, drive-by-developers, and people not as familiar with git. For <br>
these people, squash-merging makes much more sense, and when they forget <br>
to check that checkbox and someone merges their work, the result is tons <br>
of garbage commits in the git history.<br></blockquote></div></div><div dir="auto"><br></div><div>I do agree that state is a problem. Because we know that box exists we press approve when the commits themselves are garbage and then we get this mess.<br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Accordingly, I think squash-merging makes sense as the default value to <br>
avoid this. People who are comfortable with the "curated MR commit <br>
history" workflow will of course still be able to turn it off. IMO it <br>
makes more sense to ask experts to turn it off than to ask newcomers and <br>
novices to turn it on.<br>
<br>
Thoughts?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">-1</div><div dir="auto"></div><div dir="auto">New to kde doesn't mean new to git. We have a lot of skilled people, and one of the biggest gains of adopting gitlab is that we expose git more directly.<br></div><div dir="auto"><br></div><div dir="auto">Imho that feature request to gitlab to set a default isn't actually what we're after. It's requesting a bodge that replaces one problem with another.</div><div dir="auto"><br></div><div dir="auto"></div><div dir="auto">We don't want a default for a merge option, we want an exposed action like the existing rebase button to squash things within the local branch. That would mean reviewers can review commits (and therefore review commit messages properly) and you still provide an easy path for people who can't squash locally. If we only approve when commits themselves are sound, it'll be easy to manage. Win-win.<br></div><div dir="auto"></div><div dir="auto"><br></div><div>David<br></div></div>
</div>