On Wed, Sep 23, 2020 at 9:52 AM Justin Sherrill <jsher...@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. -Mike David On Wed, Sep 23, 2020 at 6:48 AM Ina Panova <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> 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 <pulp-dev-boun...@redhat.com> on >> behalf of David Davis <davidda...@redhat.com> >> *Sent:* 22 September 2020 17:16 >> *To:* Pulp-dev <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> >> 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 >> https://www.redhat.com/mailman/listinfo/pulp-dev >> > _______________________________________________ Pulp-dev mailing listPulp-dev@redhat.comhttps://www.redhat.com/mailman/listinfo/pulp-dev _______________________________________________ > Pulp-dev mailing list > Pulp-dev@redhat.com > https://www.redhat.com/mailman/listinfo/pulp-dev > -- Mike DePaulo He / Him / His Service Reliability Engineer, Pulp Red Hat <https://www.redhat.com/> IM: mikedep333 GPG: 51745404 <https://www.redhat.com/>
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev