<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 25, 2020 at 8:14 AM Matthias Dellweg <<a href="mailto:mdellweg@redhat.com">mdellweg@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>I know, this is late to the game, but i didn't have a better argument than i didn't like. Now i know why i prefer merge commits:</div><div>Having proper merge commits:</div><div>- keeps the information when a change was made and when it was merged (quba42 mentioned this before)<br></div><div>- keeps signatures on commits intakt (I know almost no one signes their commits, i do)</div></div></blockquote><div>I never thought of this, but throwing away signed commits is kind of a big deal. I love the rebase default, and don't like the merge commit option, but this is a deal-breaker for me. Over time I think we want more signed commits for project security.<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"><div dir="ltr"><div>- allows to delete your feature branches with `git branch -d` instead of `git branch -D` and thereby prevents unintentional loss of unmerged work</div><div><br></div><div>The most prominent argument i heard here was for a clean git history.</div><div>For me a clean git history should focus on the individual commit, like:</div><div>- one commit for one change</div><div>- good commit messages (<a href="https://chris.beams.io/posts/git-commit/" target="_blank">https://chris.beams.io/posts/git-commit/</a> is a very good guideline)</div><div>- keep the diff short and readable (black does a good job there with trailing commas and no hanging indents)</div><div><br></div><div>For this last bullet point, i want to suggest, that we drop the "Break documentation lines at 100 characters and try to imitate block formatting." rule.</div><div>We should break lines in rst and md files like we do in all other source code at language structures. If you have one sentence per line, and you want to change one sentence, the resulting diff reflects just that (+1-1); If you delete a phrase (-1); If you add two sentences (+2). This also helps to find the commit, a specific part of the docs was changed for real via "git blame".<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 25, 2020 at 1:11 AM David Davis <<a href="mailto:daviddavis@redhat.com" target="_blank">daviddavis@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I agree that merging by squash is potentially unsafe. I'll disable it for pulpcore and pulp_file unless anyone objects.<br clear="all"><div><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><br></div><div>David</div></div></div></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 24, 2020 at 11:56 AM Brian Bouterse <<a href="mailto:bmbouter@redhat.com" target="_blank">bmbouter@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I'm in favor of only the rebase & merge option everywhere. Our commit association machinery relies on commits not being modified, so I don't think the "squash and rebase" is a safe option for us. I am glad we are no longer using merge commits also.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 24, 2020 at 11:39 AM Tatiana Tereshchenko <<a href="mailto:ttereshc@redhat.com" target="_blank">ttereshc@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">pulp_rpm left only rebase & merge option.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 23, 2020 at 7:46 PM Mike DePaulo <<a href="mailto:mikedep333@redhat.com" target="_blank">mikedep333@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Wed, Sep 23, 2020 at 9:52 AM Justin Sherrill <<a href="mailto:jsherril@redhat.com" target="_blank">jsherril@redhat.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p><br>
</p>
<div>On 9/23/20 7:18 AM, David Davis wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">I think the two main things for me are (1) it makes
git history more linear and (2) it cuts down on the number of
commits. Both of these make git history more readable.</div></blockquote></div></blockquote><div>3rd main thing for me:<br></div><div>3. It removes extra work when rewriting history. Rewriting history is desirable in case secret keys, huge binary blobs (that degrade git performance), etc accidentally get through.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><blockquote type="cite">
</blockquote>
<p>The 'rebase and merge' option provides a nice balance of letting
you provide multiple commits and maintain commit history while not
creating a merge commit and making a hard to read commit
history. Sometimes it is more expressive to have two (or three)
commits that make up one pr to make it into the source tree.<br></p></div></blockquote><div>I agree with rebase and merge. Often I need multiple commits for that reason, or for multiple closely related (pulp_installer) tickets.<br></div><div><br></div><div>I've done this both on <a href="https://wiki.x2go.org/doku.php" target="_blank">the X2Go Project</a>, and at a previous job with a big ansible codebase.</div><div></div><div><br></div><div>-Mike<br></div><div>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>
<div>
<div dir="ltr">
<div dir="ltr">
<div>
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div>David</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, Sep 23, 2020 at 6:48
AM Ina Panova <<a href="mailto:ipanova@redhat.com" target="_blank">ipanova@redhat.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote">
<div dir="ltr">
<div dir="ltr">Hi Quirin,<br>
<div>
<div>
<div dir="ltr">
<div dir="ltr">
<div>
<div dir="ltr"><br>
<br>
--------<br>
Regards,<br>
<br>
Ina Panova<br>
Senior Software Engineer| Pulp| Red Hat Inc.<br>
<br>
"Do not go where the path may lead,<br>
go instead where there is no path and leave a
trail."<br>
</div>
</div>
</div>
</div>
</div>
<br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, Sep 23, 2020 at
10:47 AM Quirin Pamp <<a href="mailto:pamp@atix.de" target="_blank">pamp@atix.de</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote">
<div dir="ltr">
<div>
"I'd encourage plugins to consider disabling merge
by commit as well."</div>
<div>
<br>
</div>
<div>
In order to evaluate this it would be great, if you
could explain why this was decided for pulpcore and
pulp_file.</div>
<div>
You have posted a lot of general information about
the different merge type (the "What?"), but not so
much on the "Why?".</div>
<div>
<br>
</div>
<div>
As far as I can tell the main advantage of squish
and rebase, is that it leads to a more tidy history
in master, at the cost of losing some information on
how the sausage was made.</div>
<div>
As a result squish and rebase becomes increasingly
advantageous with increasing PR volume.</div>
<div>
However, I fail to see an advantage for pulp_deb,
which does not have a large PR volume.</div>
<div>
<br>
</div>
<div>
Or am I missing some relevant part of the argument?</div>
</div>
</blockquote>
<div><br>
</div>
<div>I think your understanding is correct. In my
perspective it is important to have a tidy history in
master no matter how high/low PR traffic you have.<br>
</div>
<div><br>
</div>
<div>pulp_container has disabled merge by commit as well.<br>
</div>
<blockquote class="gmail_quote">
<div dir="ltr">
<div>
<br>
</div>
<div>
Quirin<br>
</div>
<hr>
<div id="gmail-m_8110843002020665290gmail-m_-5876244713119872402gmail-m_-8278916743132037584gmail-m_101280975165329570gmail-m_-2038388437389073566gmail-m_-6069401678680623704gmail-m_8585235122672215599gmail-m_-8214920271150331018gmail-m_-1457093599685416421divRplyFwdMsg" dir="ltr"><b>From:</b> <a href="mailto:pulp-dev-bounces@redhat.com" target="_blank">pulp-dev-bounces@redhat.com</a>
<<a href="mailto:pulp-dev-bounces@redhat.com" target="_blank">pulp-dev-bounces@redhat.com</a>>
on behalf of David Davis <<a href="mailto:daviddavis@redhat.com" target="_blank">daviddavis@redhat.com</a>><br>
<b>Sent:</b> 22 September 2020 17:16<br>
<b>To:</b> Pulp-dev <<a href="mailto:pulp-dev@redhat.com" target="_blank">pulp-dev@redhat.com</a>><br>
<b>Subject:</b> Re: [Pulp-dev] Disabling merge by
commit
<div> </div>
</div>
<div>
<div dir="ltr">Here's some more information about PR
merges as well:
<div><br>
</div>
<div><a href="https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-request-merges" target="_blank">https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-request-merges</a><br>
<div>
<div dir="ltr">
<div dir="ltr">
<div>
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div><br>
</div>
<div>David</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
</div>
</div>
<br>
<div>
<div dir="ltr">On Tue, Sep 22, 2020 at 11:11 AM
David Davis <<a href="mailto:daviddavis@redhat.com" target="_blank">daviddavis@redhat.com</a>>
wrote:<br>
</div>
<blockquote>
<div dir="ltr">Today at open floor, we decided
to disable merging by commit for pulpcore and
pulp_file PRs. Instead, developers will rebase
or squash PRs to merge them. This adds the
changes to HEAD instead of
interspersing commits and creating a merge
commit. This picture of git history comparing
pulpcore to foreman (which doesn't merge by
commit) illustrates the differences:
<div><br>
</div>
<div><a href="https://imgur.com/a/uiIa0Mr" target="_blank">https://imgur.com/a/uiIa0Mr</a></div>
<div><br>
</div>
<div>I'd encourage plugins to consider
disabling merge by commit as well. To do so,
go to the settings page for your github repo
and look under the Merge Button section.<br>
<div>
<div dir="ltr">
<div dir="ltr">
<div>
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div><br>
</div>
<div>David</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
_______________________________________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-dev</a><br>
</blockquote>
</div>
</div>
</blockquote>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
Pulp-dev mailing list
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-dev</a>
</pre>
</blockquote>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
_______________________________________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-dev</a><br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr"><div dir="ltr"><p style="color:rgb(0,0,0);font-family:RedHatText,sans-serif;font-weight:bold;margin:0px;padding:0px;font-size:14px;text-transform:capitalize"><span>Mike</span> <span>DePaulo</span><span style="text-transform:uppercase;color:rgb(170,170,170);margin:0px"></span></p><p style="color:rgb(0,0,0);font-family:RedHatText,sans-serif;font-size:12px;margin:0px 0px 4px;text-transform:capitalize">He / Him / His</p><p style="color:rgb(0,0,0);font-family:RedHatText,sans-serif;font-size:12px;margin:0px;text-transform:capitalize"><span>Service Reliability Engineer, Pulp</span></p><p style="color:rgb(0,0,0);font-family:RedHatText,sans-serif;margin:0px 0px 4px;font-size:12px"><a href="https://www.redhat.com/" style="color:rgb(0,136,206);margin:0px" target="_blank">Red Hat<span></span></a></p><div style="color:rgb(0,0,0);font-family:RedHatText,sans-serif;font-size:medium;margin-bottom:4px"></div><p style="color:rgb(0,0,0);font-family:RedHatText,sans-serif;margin:0px;font-size:12px"><span>IM: <span>mikedep333</span></span></p><p style="color:rgb(0,0,0);font-family:RedHatText,sans-serif;font-size:12px;margin:0px"><span>GPG: 51745404</span></p><div style="color:rgb(0,0,0);font-family:RedHatText,sans-serif;font-size:medium;margin-top:12px"><table border="0"><tbody><tr><td width="100px"><a href="https://www.redhat.com/" target="_blank"><img src="https://marketing-outfit-prod-images.s3-us-west-2.amazonaws.com/f5445ae0c9ddafd5b2f1836854d7416a/Logo-RedHat-Email.png" width="90" height="auto"></a></td></tr></tbody></table></div></div></div></div>
_______________________________________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-dev</a><br>
</blockquote></div>
_______________________________________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-dev</a><br>
</blockquote></div>
_______________________________________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-dev</a><br>
</blockquote></div>
_______________________________________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-dev</a><br>
</blockquote></div>
_______________________________________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-dev</a><br>
</blockquote></div></div>