On 9/23/20 7:18 AM, David Davis wrote:
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.
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.
David
On Wed, Sep 23, 2020 at 6:48 AM Ina Panova <ipan...@redhat.com
<mailto:ipan...@redhat.com>> wrote:
Hi Quirin,
--------
Regards,
Ina Panova
Senior Software Engineer| Pulp| Red Hat Inc.
"Do not go where the path may lead,
go instead where there is no path and leave a trail."
On Wed, Sep 23, 2020 at 10:47 AM Quirin Pamp <p...@atix.de
<mailto:p...@atix.de>> wrote:
"I'd encourage plugins to consider disabling merge by commit
as well."
In order to evaluate this it would be great, if you could
explain why this was decided for pulpcore and pulp_file.
You have posted a lot of general information about the
different merge type (the "What?"), but not so much on the
"Why?".
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.
As a result squish and rebase becomes increasingly
advantageous with increasing PR volume.
However, I fail to see an advantage for pulp_deb, which does
not have a large PR volume.
Or am I missing some relevant part of the argument?
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.
pulp_container has disabled merge by commit as well.
Quirin
------------------------------------------------------------------------
*From:* pulp-dev-boun...@redhat.com
<mailto:pulp-dev-boun...@redhat.com>
<pulp-dev-boun...@redhat.com
<mailto:pulp-dev-boun...@redhat.com>> on behalf of David Davis
<davidda...@redhat.com <mailto:davidda...@redhat.com>>
*Sent:* 22 September 2020 17:16
*To:* Pulp-dev <pulp-dev@redhat.com <mailto:pulp-dev@redhat.com>>
*Subject:* Re: [Pulp-dev] Disabling merge by commit
Here's some more information about PR merges as well:
https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-request-merges
David
On Tue, Sep 22, 2020 at 11:11 AM David Davis
<davidda...@redhat.com <mailto:davidda...@redhat.com>> wrote:
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:
https://imgur.com/a/uiIa0Mr
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.
David
_______________________________________________
Pulp-dev mailing list
Pulp-dev@redhat.com <mailto:Pulp-dev@redhat.com>
https://www.redhat.com/mailman/listinfo/pulp-dev
_______________________________________________
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev
_______________________________________________
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev
