<div dir="ltr"><div></div><div><div>So to clarify, there are two allowed gitlab workflows.</div><div><br></div><div>MRs for chains of nicely done rebased commits</div><div>MRs where one MR represents a single logical commit to be squashed and the list of actual commits uploaded is garbage.</div></div><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
One issue with such a workflow is that code reviewers will have to <br>
accumulate all commits in their mind. Speaking for myself, that is <br>
really difficult.<br></blockquote><div><br></div><div>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.</div><div>It's normally clear from the commit names.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Another issue is that it's not clear how the commits are going to be <br>
squashed, which makes it even more hard to add "ship it."<br>
</blockquote><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
For example, let's consider that a person has created a merge request <br>
with two commits<br></blockquote><div> </div><div>If the person is good at git, they'll squash C locally before force pushing.</div><div>If the person is not, they should just have made two merge requests to begin with. </div><div><br></div><div>I think we can certainly encourage the good git pattern especially for an advanced complicated multi-commit branch.<br></div><div>it's just a case of finding a balance for the people just doing really simple changes.</div><div><br></div><div>David<br></div></div></div>