[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Proposal: make squash-merging the default behavior for gitlab MRs
From:       David Edmundson <david () davidedmundson ! co ! uk>
Date:       2020-10-03 12:10:25
Message-ID: CAGeFrHDQCxoLE-aa_3GQh5DFOEOb6bWTkw=crw3Oq62Uoka4Ag () mail ! gmail ! com
[Download RAW message or body]

>
> your_merge_request_commit_history
> <https://community.kde.org/Infrastructure/GitLab#Curating_your_merge_request_commit_history>
> .
>
> However, it remains a fairly advanced workflow which is challenging for
> newcomers, drive-by-developers, and people not as familiar with git. For
> these people, squash-merging makes much more sense, and when they forget
> to check that checkbox and someone merges their work, the result is tons
> of garbage commits in the git history.
>

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.

Accordingly, I think squash-merging makes sense as the default value to
> avoid this. People who are comfortable with the "curated MR commit
> history" workflow will of course still be able to turn it off. IMO it
> makes more sense to ask experts to turn it off than to ask newcomers and
> novices to turn it on.
>
> Thoughts?
>

-1
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.

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.

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.

David

[Attachment #3 (text/html)]

<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 &quot;curated MR commit <br> history&quot; 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&#39;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&#39;t actually \
what we&#39;re after. It&#39;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&#39;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&#39;t squash locally. If we only \
approve when commits themselves are sound, it&#39;ll be easy to manage. \
Win-win.<br></div><div dir="auto"></div><div \
dir="auto"><br></div><div>David<br></div></div> </div>



[prev in list] [next in list] [prev in thread] [next in thread]