[Pulp-dev] Disabling merge by commit
mikedep333 at redhat.com
Wed Sep 23 17:46:32 UTC 2020
On Wed, Sep 23, 2020 at 9:52 AM Justin Sherrill <jsherril at redhat.com> wrote:
> 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.
> 3rd main thing for me:
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.
> 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.
I agree with rebase and merge. Often I need multiple commits for that
reason, or for multiple closely related (pulp_installer) tickets.
I've done this both on the X2Go Project <https://wiki.x2go.org/doku.php>,
and at a previous job with a big ansible codebase.
On Wed, Sep 23, 2020 at 6:48 AM Ina Panova <ipanova at redhat.com> wrote:
> Hi Quirin,
> 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 <pamp at 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.
>> *From:* pulp-dev-bounces at redhat.com <pulp-dev-bounces at redhat.com> on
>> behalf of David Davis <daviddavis at redhat.com>
>> *Sent:* 22 September 2020 17:16
>> *To:* Pulp-dev <pulp-dev at redhat.com>
>> *Subject:* Re: [Pulp-dev] Disabling merge by commit
>> Here's some more information about PR merges as well:
>> On Tue, Sep 22, 2020 at 11:11 AM David Davis <daviddavis at redhat.com>
>> 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:
>> 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.
>> Pulp-dev mailing list
>> Pulp-dev at redhat.com
listPulp-dev at redhat.comhttps://www.redhat.com/mailman/listinfo/pulp-dev
> Pulp-dev mailing list
> Pulp-dev at redhat.com
He / Him / His
Service Reliability Engineer, Pulp
Red Hat <https://www.redhat.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pulp-dev