Lazy consensus: Merging options

62 views
Skip to first unread message

Ben Kochie

unread,
Dec 3, 2020, 8:15:46 AM12/3/20
to Prometheus Developers
I'd like to adjust our defaults for GitHub merging settings:

Right now, we allow all three modes for PR merges.
* Merge commits
* Squash merging
* Rebase merging

Proposal: Remove rebase merging (aka fast-forward merges) so that we stick to merge/squash and merge.

image.png

Brian Brazil

unread,
Dec 3, 2020, 8:20:35 AM12/3/20
to Ben Kochie, Prometheus Developers
I use rebase merges sometimes to keep the history clean from unnecessary merge commits, so I'd like it to hang around.

Brian
 

image.png

--
You received this message because you are subscribed to the Google Groups "Prometheus Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-devel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/CABbyFmp0X26pjfvyATvaUxH9p_nwBh0QSMgtJGNzfDLnZJjdMQ%40mail.gmail.com.


--

Bartłomiej Płotka

unread,
Dec 3, 2020, 9:00:05 AM12/3/20
to Brian Brazil, Ben Kochie, Prometheus Developers
I am ok with this proposal.

Long term I would even vote for squash only, but we discussed this in the past.

Kind Regards,
Bartek Płotka (@bwplotka)


Julien Pivotto

unread,
Dec 3, 2020, 9:06:47 AM12/3/20
to Bartłomiej Płotka, Brian Brazil, Ben Kochie, Prometheus Developers
On 03 Dec 14:59, Bartłomiej Płotka wrote:
> I am ok with this proposal.
>
> Long term I would even vote for squash only, but we discussed this in the
> past.

How would you merge release branches in master?

>
> Kind Regards,
> Bartek Płotka (@bwplotka)
>
>
> On Thu, 3 Dec 2020 at 14:20, Brian Brazil <brian....@robustperception.io>
> wrote:
>
> > On Thu, 3 Dec 2020 at 13:15, Ben Kochie <sup...@gmail.com> wrote:
> >
> >> I'd like to adjust our defaults for GitHub merging settings:
> >>
> >> Right now, we allow all three modes for PR merges.
> >> * Merge commits
> >> * Squash merging
> >> * Rebase merging
> >>
> >> Proposal: Remove rebase merging (aka fast-forward merges) so that we
> >> stick to merge/squash and merge.
> >>
> >
> > I use rebase merges sometimes to keep the history clean from
> > unnecessary merge commits, so I'd like it to hang around.
> >
> > Brian
> >
> >
> >>
> >> [image: image.png]
> >>
> >> --
> >> You received this message because you are subscribed to the Google Groups
> >> "Prometheus Developers" group.
> >> To unsubscribe from this group and stop receiving emails from it, send an
> >> email to prometheus-devel...@googlegroups.com.
> >> To view this discussion on the web visit
> >> https://groups.google.com/d/msgid/prometheus-developers/CABbyFmp0X26pjfvyATvaUxH9p_nwBh0QSMgtJGNzfDLnZJjdMQ%40mail.gmail.com
> >> <https://groups.google.com/d/msgid/prometheus-developers/CABbyFmp0X26pjfvyATvaUxH9p_nwBh0QSMgtJGNzfDLnZJjdMQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> >> .
> >>
> >
> >
> > --
> > Brian Brazil
> > www.robustperception.io
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Prometheus Developers" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to prometheus-devel...@googlegroups.com.
> > To view this discussion on the web visit
> > https://groups.google.com/d/msgid/prometheus-developers/CAHJKeLpwuPY6iE0k7zRP8PFAGTrEx9hYzx6j%3DQT8p4hLQVF6-w%40mail.gmail.com
> > <https://groups.google.com/d/msgid/prometheus-developers/CAHJKeLpwuPY6iE0k7zRP8PFAGTrEx9hYzx6j%3DQT8p4hLQVF6-w%40mail.gmail.com?utm_medium=email&utm_source=footer>
> > .
> >
>
> --
> You received this message because you are subscribed to the Google Groups "Prometheus Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-devel...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/CAMssQwahWTP3uPQuEDcu8jQB_EBDe5AOKXrJYd6%2Bad-wqOpEFQ%40mail.gmail.com.



--
Julien Pivotto
@roidelapluie

Frederic Branczyk

unread,
Dec 3, 2020, 9:27:23 AM12/3/20
to Bartłomiej Płotka, Ben Kochie, Brian Brazil, Prometheus Developers
I don’t like squash merging, don’t think I’ve ever used rebase merging but don’t feel too strongly about it. Merge commit is my preference. 

Brian Brazil

unread,
Dec 3, 2020, 10:11:12 AM12/3/20
to Frederic Branczyk, Bartłomiej Płotka, Ben Kochie, Prometheus Developers
On Thu, 3 Dec 2020 at 14:27, Frederic Branczyk <fbra...@gmail.com> wrote:
I don’t like squash merging, don’t think I’ve ever used rebase merging but don’t feel too strongly about it. Merge commit is my preference. 

Many PRs I see end up with lots of tiny commits as part of the review process that need to be squashed. I find it's handy to be able to do all of that when I merge (and also fix up the commit description), rather than doing another roundtrip with the author.

Brian

Bartłomiej Płotka

unread,
Dec 3, 2020, 10:32:24 AM12/3/20
to Brian Brazil, Frederic Branczyk, Ben Kochie, Prometheus Developers
> How would you merge release branches in master?

Unpopular opinion: I would squash them. At the end there will be conflicts anyway, that will require this, there is zero advantage in doing merge commit - it just obfuscates git history to me (: 

Anyway I feel like we are aiming towards both Squash AND Merge options (: 

Kind Regards,
Bartek Płotka (@bwplotka)

Julien Pivotto

unread,
Dec 3, 2020, 10:54:37 AM12/3/20
to Bartłomiej Płotka, Brian Brazil, Frederic Branczyk, Ben Kochie, Prometheus Developers
On 03 Dec 16:32, Bartłomiej Płotka wrote:
> > How would you merge release branches in master?
>
> Unpopular opinion: I would squash them. At the end there will be
> conflicts anyway, that will require this, there is zero advantage in doing
> merge commit - it just obfuscates git history to me (:
>
> Anyway I feel like we are aiming towards both Squash AND Merge options (:

Are you dismissing Brian's comment?

There is a big advantage in merge commit for releases, which is to be
able to see which branches has been merged.

No, the solution for conflit is not squash, it is manual merge commit.
> To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/CAMssQwZ0MJ2gJiw1jp--gbQBVqdLzGuVxRSM6wP7TZfYes9tRA%40mail.gmail.com.

--
Julien Pivotto
@roidelapluie

Sylvain Rabot

unread,
Dec 3, 2020, 10:55:52 AM12/3/20
to Frederic Branczyk, Bartłomiej Płotka, Ben Kochie, Brian Brazil, Prometheus Developers
I also don’t like squashing.

I don’t count the hours lost because I thought a commit referenced in a merged PR was not in a tag because the squash generated a new commit id.

On 3 Dec 2020, at 15:27, Frederic Branczyk <fbra...@gmail.com> wrote:



Ben Kochie

unread,
Dec 3, 2020, 11:00:19 AM12/3/20
to Sylvain Rabot, Frederic Branczyk, Bartłomiej Płotka, Brian Brazil, Prometheus Developers
I agree, I tend to avoid squashing unless the PR author generates a really messy set of "fix typo" commits, rather than maintaining a clean PR branch.

Bjoern Rabenstein

unread,
Dec 3, 2020, 12:47:11 PM12/3/20
to Ben Kochie, Prometheus Developers
Clearly, merge commits and squashing happens most often.

I can see the occasional need for a rebase.

Even though I am a firm advocate of avoiding commit rewriting whenever
reasonably passible, I do think we need to keep the other options
around.

--
Björn Rabenstein
[PGP-ID] 0x851C3DA17D748D03
[email] bjo...@rabenste.in

Sylvain Rabot

unread,
Dec 3, 2020, 12:50:53 PM12/3/20
to Frederic Branczyk, Bartłomiej Płotka, Ben Kochie, Brian Brazil, Prometheus Developers
Squashing and rebasing also sucks for people who sign their commits.
--
Sylvain Rabot <syl...@abstraction.fr>

Matthias Rampke

unread,
Dec 4, 2020, 2:13:54 AM12/4/20
to Sylvain Rabot, Frederic Branczyk, Bartłomiej Płotka, Ben Kochie, Brian Brazil, Prometheus Developers
… which we used to encourage inside the team.

I prefer real merging too, I like git and I don't feel the need to make history linear.

I don't use rebase merging from PRs but I also don't think we should remove that while allowing squash merging. I am okay with every maintainer having their own style.

/MR

Reply all
Reply to author
Forward
0 new messages