You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pekko.apache.org by Matthew Benedict de Detrich <ma...@aiven.io.INVALID> on 2022/11/03 16:04:45 UTC
Forcing rebase/squash and merge for PR merged into Pekko
I just noticed that when https://github.com/apache/incubator-pekko/pull/5 was merged it was done via a merge commit. I think that this is a good time to discuss what method of merging we should use. I would stick with rebase/squash and merge because if you look at the git history of Akka you can see that we don’t use merge commits. I just asked a fellow Flink committer how this is done (since Flink also has the same setup, i.e. no merge commits) and apparently a PMC member has to directly set it in the GitHub settings.
@PJ Fanning, if we end up enforcing this on https://github.com/apache/incubator-pekko then I would recommend rebase the current main branch and pushing it to get rid of the merge commit so the git history is clean.
--
Matthew de Detrich
Aiven Deutschland GmbH
Immanuelkirchstraße 26, 10405 Berlin
Amtsgericht Charlottenburg, HRB 209739 B
Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
m: +491603708037
w: aiven.io e: matthew.dedetrich@aiven.io
Re: Forcing rebase/squash and merge for PR merged into Pekko
Posted by Matthew Benedict de Detrich <ma...@aiven.io.INVALID>.
> We use signed commits at $work and when you enable that it will fail to
rebase in the GH UI because it can't do so without destroying signatures
and it only wants to sign squashes and merge commits (and commits authored
in GH UI). Which is what led me to kick this discussion into motion. 🤷♂️
Right this is true, the signature will be destroyed when it gets merged
into main but you can still verify that the PR just before it did get
merged into main is verified which may be enough.
Anyways as you said this is going around in circles, let's make
another discussion for it if we still want to discuss it.
On Tue, Nov 8, 2022 at 11:11 AM Jean-Luc Deprez <Je...@gmail.com>
wrote:
> Mhaha, now it's starting to go in circles.
>
> We use signed commits at $work and when you enable that it will fail to
> rebase in the GH UI because it can't do so without destroying signatures
> and it only wants to sign squashes and merge commits (and commits authored
> in GH UI). Which is what led me to kick this discussion into motion. 🤷♂️
>
> It also has a nasty bug btw. You can't set branch creation protection to
> require commit signing or it will try to validate the whole Git log and you
> only need a few thousand signed commits to have it time out.
>
>
>
> On Tue, Nov 8, 2022 at 11:00 AM Matthew Benedict de Detrich
> <ma...@aiven.io.invalid> wrote:
>
> > On a similar note on this topic, it is actually possible to do even
> > "precise verification" via Github but it's a different way of doing
> things.
> > Now that pekko's main branch is protected (see
> > https://github.com/apache/incubator-pekko/pull/29) it's also possible to
> > turn on GPG signature verification. What this means is that you
> > cannot merge a PR into main unless all of the commits have been signed by
> > the original creators of the commit.
> >
> > What this does is that it verifies that whenever code has been merged
> into
> > main, the state of the code beforehand (i.e. as a PR) has been signed by
> > the author's of that PR. So while commits that get merged into main are
> not
> > verified, the code just before the merge is verified and since the branch
> > is protected (i.e. no one can directly push to it) the argument could be
> > made that even in extreme cases this is enough to prove authorship even
> > down to the technical signature level.
> >
> > I would like to at some point turn on signature verification however it
> > requires everyone to setup a key and submit their public key to github so
> > it can possibly reduce collaboration. I would say such a move would need
> a
> > binding vote and its a discussion for another day.
> >
> > On Tue, Nov 8, 2022 at 10:33 AM Jean-Luc Deprez <
> JeanLuc.Deprez@gmail.com>
> > wrote:
> >
> > > For copyright entitlement attribution by author tag or Co-authored-by
> tag
> > > should suffice. (possibly augmented by a copyright line in the file
> > > header).
> > >
> > > Committer identity (in Git by digital signatures) matters if you
> require
> > > 'an audit trail / forensic evidence'. So it only really starts
> mattering
> > > when in a dark place already, but that's how most deterrents work and
> > > plenty of those in the world.
> > >
> > > (not an argument to start doing that, just a response to Justin)
> > >
> > >
> > > On Tue, Nov 8, 2022 at 9:51 AM Matthew Benedict de Detrich
> > > <ma...@aiven.io.invalid> wrote:
> > >
> > > > Right this I understand, when I said "precise" traceability I was
> > talking
> > > > about precise tracking via git commit's which is not necessarily the
> > same
> > > > thing as knowing who wrote which code (this was in context of github
> > > > creating its own commits because we do a rebase via the github UI).
> > With
> > > > this example of Github UI, in such a case it's still very clear who
> > wrote
> > > > the code but it doesn't perfectly align with the "traditional git
> way".
> > > >
> > > > On Tue, Nov 8, 2022 at 9:36 AM Justin Mclean <
> justin@classsoftware.com
> > >
> > > > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > > Precise traceability of who wrote which exact portions code isn't
> > of
> > > > any
> > > > > > critical importance in open source projects, authorship is.
> > > > >
> > > > >
> > > > > IMO, who wrote the code determines who owns it (them or their
> > > employer),
> > > > > and that impacts how it can be licensed and if that can be
> > contributed
> > > to
> > > > > an ASF project. This is critical, even if it rarely an issue.
> > > > >
> > > > > Kind Regards,
> > > > > Justin
> > > >
> > > >
> > > >
> > > > --
> > > >
> > > > Matthew de Detrich
> > > >
> > > > *Aiven Deutschland GmbH*
> > > >
> > > > Immanuelkirchstraße 26, 10405 Berlin
> > > >
> > > > Amtsgericht Charlottenburg, HRB 209739 B
> > > >
> > > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> > > >
> > > > *m:* +491603708037
> > > >
> > > > *w:* aiven.io *e:* matthew.dedetrich@aiven.io
> > > >
> > >
> >
> >
> > --
> >
> > Matthew de Detrich
> >
> > *Aiven Deutschland GmbH*
> >
> > Immanuelkirchstraße 26, 10405 Berlin
> >
> > Amtsgericht Charlottenburg, HRB 209739 B
> >
> > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> >
> > *m:* +491603708037
> >
> > *w:* aiven.io *e:* matthew.dedetrich@aiven.io
> >
>
--
Matthew de Detrich
*Aiven Deutschland GmbH*
Immanuelkirchstraße 26, 10405 Berlin
Amtsgericht Charlottenburg, HRB 209739 B
Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
*m:* +491603708037
*w:* aiven.io *e:* matthew.dedetrich@aiven.io
Re: Forcing rebase/squash and merge for PR merged into Pekko
Posted by Jean-Luc Deprez <Je...@gmail.com>.
Mhaha, now it's starting to go in circles.
We use signed commits at $work and when you enable that it will fail to
rebase in the GH UI because it can't do so without destroying signatures
and it only wants to sign squashes and merge commits (and commits authored
in GH UI). Which is what led me to kick this discussion into motion. 🤷♂️
It also has a nasty bug btw. You can't set branch creation protection to
require commit signing or it will try to validate the whole Git log and you
only need a few thousand signed commits to have it time out.
On Tue, Nov 8, 2022 at 11:00 AM Matthew Benedict de Detrich
<ma...@aiven.io.invalid> wrote:
> On a similar note on this topic, it is actually possible to do even
> "precise verification" via Github but it's a different way of doing things.
> Now that pekko's main branch is protected (see
> https://github.com/apache/incubator-pekko/pull/29) it's also possible to
> turn on GPG signature verification. What this means is that you
> cannot merge a PR into main unless all of the commits have been signed by
> the original creators of the commit.
>
> What this does is that it verifies that whenever code has been merged into
> main, the state of the code beforehand (i.e. as a PR) has been signed by
> the author's of that PR. So while commits that get merged into main are not
> verified, the code just before the merge is verified and since the branch
> is protected (i.e. no one can directly push to it) the argument could be
> made that even in extreme cases this is enough to prove authorship even
> down to the technical signature level.
>
> I would like to at some point turn on signature verification however it
> requires everyone to setup a key and submit their public key to github so
> it can possibly reduce collaboration. I would say such a move would need a
> binding vote and its a discussion for another day.
>
> On Tue, Nov 8, 2022 at 10:33 AM Jean-Luc Deprez <Je...@gmail.com>
> wrote:
>
> > For copyright entitlement attribution by author tag or Co-authored-by tag
> > should suffice. (possibly augmented by a copyright line in the file
> > header).
> >
> > Committer identity (in Git by digital signatures) matters if you require
> > 'an audit trail / forensic evidence'. So it only really starts mattering
> > when in a dark place already, but that's how most deterrents work and
> > plenty of those in the world.
> >
> > (not an argument to start doing that, just a response to Justin)
> >
> >
> > On Tue, Nov 8, 2022 at 9:51 AM Matthew Benedict de Detrich
> > <ma...@aiven.io.invalid> wrote:
> >
> > > Right this I understand, when I said "precise" traceability I was
> talking
> > > about precise tracking via git commit's which is not necessarily the
> same
> > > thing as knowing who wrote which code (this was in context of github
> > > creating its own commits because we do a rebase via the github UI).
> With
> > > this example of Github UI, in such a case it's still very clear who
> wrote
> > > the code but it doesn't perfectly align with the "traditional git way".
> > >
> > > On Tue, Nov 8, 2022 at 9:36 AM Justin Mclean <justin@classsoftware.com
> >
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > > Precise traceability of who wrote which exact portions code isn't
> of
> > > any
> > > > > critical importance in open source projects, authorship is.
> > > >
> > > >
> > > > IMO, who wrote the code determines who owns it (them or their
> > employer),
> > > > and that impacts how it can be licensed and if that can be
> contributed
> > to
> > > > an ASF project. This is critical, even if it rarely an issue.
> > > >
> > > > Kind Regards,
> > > > Justin
> > >
> > >
> > >
> > > --
> > >
> > > Matthew de Detrich
> > >
> > > *Aiven Deutschland GmbH*
> > >
> > > Immanuelkirchstraße 26, 10405 Berlin
> > >
> > > Amtsgericht Charlottenburg, HRB 209739 B
> > >
> > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> > >
> > > *m:* +491603708037
> > >
> > > *w:* aiven.io *e:* matthew.dedetrich@aiven.io
> > >
> >
>
>
> --
>
> Matthew de Detrich
>
> *Aiven Deutschland GmbH*
>
> Immanuelkirchstraße 26, 10405 Berlin
>
> Amtsgericht Charlottenburg, HRB 209739 B
>
> Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
>
> *m:* +491603708037
>
> *w:* aiven.io *e:* matthew.dedetrich@aiven.io
>
Re: Forcing rebase/squash and merge for PR merged into Pekko
Posted by Matthew Benedict de Detrich <ma...@aiven.io.INVALID>.
On a similar note on this topic, it is actually possible to do even
"precise verification" via Github but it's a different way of doing things.
Now that pekko's main branch is protected (see
https://github.com/apache/incubator-pekko/pull/29) it's also possible to
turn on GPG signature verification. What this means is that you
cannot merge a PR into main unless all of the commits have been signed by
the original creators of the commit.
What this does is that it verifies that whenever code has been merged into
main, the state of the code beforehand (i.e. as a PR) has been signed by
the author's of that PR. So while commits that get merged into main are not
verified, the code just before the merge is verified and since the branch
is protected (i.e. no one can directly push to it) the argument could be
made that even in extreme cases this is enough to prove authorship even
down to the technical signature level.
I would like to at some point turn on signature verification however it
requires everyone to setup a key and submit their public key to github so
it can possibly reduce collaboration. I would say such a move would need a
binding vote and its a discussion for another day.
On Tue, Nov 8, 2022 at 10:33 AM Jean-Luc Deprez <Je...@gmail.com>
wrote:
> For copyright entitlement attribution by author tag or Co-authored-by tag
> should suffice. (possibly augmented by a copyright line in the file
> header).
>
> Committer identity (in Git by digital signatures) matters if you require
> 'an audit trail / forensic evidence'. So it only really starts mattering
> when in a dark place already, but that's how most deterrents work and
> plenty of those in the world.
>
> (not an argument to start doing that, just a response to Justin)
>
>
> On Tue, Nov 8, 2022 at 9:51 AM Matthew Benedict de Detrich
> <ma...@aiven.io.invalid> wrote:
>
> > Right this I understand, when I said "precise" traceability I was talking
> > about precise tracking via git commit's which is not necessarily the same
> > thing as knowing who wrote which code (this was in context of github
> > creating its own commits because we do a rebase via the github UI). With
> > this example of Github UI, in such a case it's still very clear who wrote
> > the code but it doesn't perfectly align with the "traditional git way".
> >
> > On Tue, Nov 8, 2022 at 9:36 AM Justin Mclean <ju...@classsoftware.com>
> > wrote:
> >
> > > Hi,
> > >
> > > > Precise traceability of who wrote which exact portions code isn't of
> > any
> > > > critical importance in open source projects, authorship is.
> > >
> > >
> > > IMO, who wrote the code determines who owns it (them or their
> employer),
> > > and that impacts how it can be licensed and if that can be contributed
> to
> > > an ASF project. This is critical, even if it rarely an issue.
> > >
> > > Kind Regards,
> > > Justin
> >
> >
> >
> > --
> >
> > Matthew de Detrich
> >
> > *Aiven Deutschland GmbH*
> >
> > Immanuelkirchstraße 26, 10405 Berlin
> >
> > Amtsgericht Charlottenburg, HRB 209739 B
> >
> > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> >
> > *m:* +491603708037
> >
> > *w:* aiven.io *e:* matthew.dedetrich@aiven.io
> >
>
--
Matthew de Detrich
*Aiven Deutschland GmbH*
Immanuelkirchstraße 26, 10405 Berlin
Amtsgericht Charlottenburg, HRB 209739 B
Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
*m:* +491603708037
*w:* aiven.io *e:* matthew.dedetrich@aiven.io
Re: Forcing rebase/squash and merge for PR merged into Pekko
Posted by Jean-Luc Deprez <Je...@gmail.com>.
Git commit author tags. Not doc @author tags.
The license header presents a nice new challenge though, but that justifies
a separate thread.
On Tue, Nov 8, 2022 at 1:42 PM Justin Mclean <ju...@classsoftware.com>
wrote:
> Hi,
>
> > For copyright entitlement attribution by author tag or Co-authored-by tag
> > should suffice. (possibly augmented by a copyright line in the file
> header).
>
> The standard ASF header doesn’t include a copyright line for the author(s)
> of the code.. Also author tags are generally discouraged.
>
> Kind Regards,
> Justin
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> For additional commands, e-mail: dev-help@pekko.apache.org
>
>
Re: Forcing rebase/squash and merge for PR merged into Pekko
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> For copyright entitlement attribution by author tag or Co-authored-by tag
> should suffice. (possibly augmented by a copyright line in the file header).
The standard ASF header doesn’t include a copyright line for the author(s) of the code.. Also author tags are generally discouraged.
Kind Regards,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
For additional commands, e-mail: dev-help@pekko.apache.org
Re: Forcing rebase/squash and merge for PR merged into Pekko
Posted by Jean-Luc Deprez <Je...@gmail.com>.
For copyright entitlement attribution by author tag or Co-authored-by tag
should suffice. (possibly augmented by a copyright line in the file header).
Committer identity (in Git by digital signatures) matters if you require
'an audit trail / forensic evidence'. So it only really starts mattering
when in a dark place already, but that's how most deterrents work and
plenty of those in the world.
(not an argument to start doing that, just a response to Justin)
On Tue, Nov 8, 2022 at 9:51 AM Matthew Benedict de Detrich
<ma...@aiven.io.invalid> wrote:
> Right this I understand, when I said "precise" traceability I was talking
> about precise tracking via git commit's which is not necessarily the same
> thing as knowing who wrote which code (this was in context of github
> creating its own commits because we do a rebase via the github UI). With
> this example of Github UI, in such a case it's still very clear who wrote
> the code but it doesn't perfectly align with the "traditional git way".
>
> On Tue, Nov 8, 2022 at 9:36 AM Justin Mclean <ju...@classsoftware.com>
> wrote:
>
> > Hi,
> >
> > > Precise traceability of who wrote which exact portions code isn't of
> any
> > > critical importance in open source projects, authorship is.
> >
> >
> > IMO, who wrote the code determines who owns it (them or their employer),
> > and that impacts how it can be licensed and if that can be contributed to
> > an ASF project. This is critical, even if it rarely an issue.
> >
> > Kind Regards,
> > Justin
>
>
>
> --
>
> Matthew de Detrich
>
> *Aiven Deutschland GmbH*
>
> Immanuelkirchstraße 26, 10405 Berlin
>
> Amtsgericht Charlottenburg, HRB 209739 B
>
> Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
>
> *m:* +491603708037
>
> *w:* aiven.io *e:* matthew.dedetrich@aiven.io
>
Re: Forcing rebase/squash and merge for PR merged into Pekko
Posted by Matthew Benedict de Detrich <ma...@aiven.io.INVALID>.
Right this I understand, when I said "precise" traceability I was talking
about precise tracking via git commit's which is not necessarily the same
thing as knowing who wrote which code (this was in context of github
creating its own commits because we do a rebase via the github UI). With
this example of Github UI, in such a case it's still very clear who wrote
the code but it doesn't perfectly align with the "traditional git way".
On Tue, Nov 8, 2022 at 9:36 AM Justin Mclean <ju...@classsoftware.com>
wrote:
> Hi,
>
> > Precise traceability of who wrote which exact portions code isn't of any
> > critical importance in open source projects, authorship is.
>
>
> IMO, who wrote the code determines who owns it (them or their employer),
> and that impacts how it can be licensed and if that can be contributed to
> an ASF project. This is critical, even if it rarely an issue.
>
> Kind Regards,
> Justin
--
Matthew de Detrich
*Aiven Deutschland GmbH*
Immanuelkirchstraße 26, 10405 Berlin
Amtsgericht Charlottenburg, HRB 209739 B
Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
*m:* +491603708037
*w:* aiven.io *e:* matthew.dedetrich@aiven.io
Re: Forcing rebase/squash and merge for PR merged into Pekko
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Precise traceability of who wrote which exact portions code isn't of any
> critical importance in open source projects, authorship is.
IMO, who wrote the code determines who owns it (them or their employer), and that impacts how it can be licensed and if that can be contributed to an ASF project. This is critical, even if it rarely an issue.
Kind Regards,
Justin
Re: Forcing rebase/squash and merge for PR merged into Pekko
Posted by Matthew Benedict de Detrich <ma...@aiven.io.INVALID>.
I would say so. Anyone is free to reopen this discussion but I suspect that
unless we hit some critical problem, changing the status quo won't get much
traction.
On Mon, 7 Nov 2022, 16:16 Jean-Luc Deprez, <Je...@gmail.com> wrote:
> Could be better, could be worse, it's workable.
>
> So linear history then?
>
> On Mon, Nov 7, 2022 at 3:58 PM Matthew Benedict de Detrich
> <ma...@aiven.io.invalid> wrote:
>
> > > I guess the one remaining thing that bugs me about the rebase option is
> > that I think you loose the link with the PR, which you would get in the
> > merge (or squash) commit otherwise.
> >
> > Github PR search actually works with rebased commits. i.e. if you copy
> the
> > hash from git log you can then just search PR's with that hash. As an
> > example, the latest commit hash right now for a PR merged with rebase
> > is 373e87edaae027acf4869540daa8467007f89aac (which is the git log). You
> can
> > then just go to the pull requests tab in github and place that in the
> > search field and the PR will come up (make sure to remove the is:open
> > query), i.e.
> >
> >
> https://github.com/apache/incubator-pekko/pulls?q=is%3Apr+373e87edaae027acf4869540daa8467007f89aac
> > .
> > The github website also tells you what the new commit hash for the rebase
> > will be on the PR.
> >
> > On Mon, Nov 7, 2022 at 3:49 PM Jean-Luc Deprez <JeanLuc.Deprez@gmail.com
> >
> > wrote:
> >
> > > >
> > > > Not sure what the point is? That git requires signatures for
> > > > authentication (like many decentralized protocols) while svn was
> based
> > > > on client-server-based authentication?
> > > >
> > >
> > > Indeed
> > >
> > > This was not related to git at all, is it? It is more about some kind
> > > > of social engineering to get changes accepted (which are hard to
> > > > counter for projects on the scale of Linux).
> > > >
> > >
> > > Correct. TBH you don't need the size of the Linux kernel to be
> > susceptible
> > > to this.
> > >
> > > Precise traceability of who wrote which exact portions code isn't of
> any
> > > > critical importance in open source projects, authorship is. You have
> > > > ...
> > > > whole point of the CLA/Apache Foundation, one of its main goals is to
> > > > actually to protect individuals.
> > > >
> > >
> > > I guess that's what I aimed to say with "enterprise thinking".
> > >
> > > If commit signing is deemed irrelevant, the importance of merge commits
> > > drops indeed.
> > >
> > > Which reduces the "discussion" to, should merge commits still be
> allowed
> > in
> > > certain cases or should that always be a rebase no matter the size of
> the
> > > incoming work? (aka. linear history)
> > >
> > > I guess the one remaining thing that bugs me about the rebase option is
> > > that I think you loose the link with the PR, which you would get in the
> > > merge (or squash) commit otherwise.
> > >
> >
> >
> > --
> >
> > Matthew de Detrich
> >
> > *Aiven Deutschland GmbH*
> >
> > Immanuelkirchstraße 26, 10405 Berlin
> >
> > Amtsgericht Charlottenburg, HRB 209739 B
> >
> > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> >
> > *m:* +491603708037
> >
> > *w:* aiven.io *e:* matthew.dedetrich@aiven.io
> >
>
Re: Forcing rebase/squash and merge for PR merged into Pekko
Posted by Jean-Luc Deprez <Je...@gmail.com>.
Could be better, could be worse, it's workable.
So linear history then?
On Mon, Nov 7, 2022 at 3:58 PM Matthew Benedict de Detrich
<ma...@aiven.io.invalid> wrote:
> > I guess the one remaining thing that bugs me about the rebase option is
> that I think you loose the link with the PR, which you would get in the
> merge (or squash) commit otherwise.
>
> Github PR search actually works with rebased commits. i.e. if you copy the
> hash from git log you can then just search PR's with that hash. As an
> example, the latest commit hash right now for a PR merged with rebase
> is 373e87edaae027acf4869540daa8467007f89aac (which is the git log). You can
> then just go to the pull requests tab in github and place that in the
> search field and the PR will come up (make sure to remove the is:open
> query), i.e.
>
> https://github.com/apache/incubator-pekko/pulls?q=is%3Apr+373e87edaae027acf4869540daa8467007f89aac
> .
> The github website also tells you what the new commit hash for the rebase
> will be on the PR.
>
> On Mon, Nov 7, 2022 at 3:49 PM Jean-Luc Deprez <Je...@gmail.com>
> wrote:
>
> > >
> > > Not sure what the point is? That git requires signatures for
> > > authentication (like many decentralized protocols) while svn was based
> > > on client-server-based authentication?
> > >
> >
> > Indeed
> >
> > This was not related to git at all, is it? It is more about some kind
> > > of social engineering to get changes accepted (which are hard to
> > > counter for projects on the scale of Linux).
> > >
> >
> > Correct. TBH you don't need the size of the Linux kernel to be
> susceptible
> > to this.
> >
> > Precise traceability of who wrote which exact portions code isn't of any
> > > critical importance in open source projects, authorship is. You have
> > > ...
> > > whole point of the CLA/Apache Foundation, one of its main goals is to
> > > actually to protect individuals.
> > >
> >
> > I guess that's what I aimed to say with "enterprise thinking".
> >
> > If commit signing is deemed irrelevant, the importance of merge commits
> > drops indeed.
> >
> > Which reduces the "discussion" to, should merge commits still be allowed
> in
> > certain cases or should that always be a rebase no matter the size of the
> > incoming work? (aka. linear history)
> >
> > I guess the one remaining thing that bugs me about the rebase option is
> > that I think you loose the link with the PR, which you would get in the
> > merge (or squash) commit otherwise.
> >
>
>
> --
>
> Matthew de Detrich
>
> *Aiven Deutschland GmbH*
>
> Immanuelkirchstraße 26, 10405 Berlin
>
> Amtsgericht Charlottenburg, HRB 209739 B
>
> Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
>
> *m:* +491603708037
>
> *w:* aiven.io *e:* matthew.dedetrich@aiven.io
>
Re: Forcing rebase/squash and merge for PR merged into Pekko
Posted by Matthew Benedict de Detrich <ma...@aiven.io.INVALID>.
> I guess the one remaining thing that bugs me about the rebase option is
that I think you loose the link with the PR, which you would get in the
merge (or squash) commit otherwise.
Github PR search actually works with rebased commits. i.e. if you copy the
hash from git log you can then just search PR's with that hash. As an
example, the latest commit hash right now for a PR merged with rebase
is 373e87edaae027acf4869540daa8467007f89aac (which is the git log). You can
then just go to the pull requests tab in github and place that in the
search field and the PR will come up (make sure to remove the is:open
query), i.e.
https://github.com/apache/incubator-pekko/pulls?q=is%3Apr+373e87edaae027acf4869540daa8467007f89aac.
The github website also tells you what the new commit hash for the rebase
will be on the PR.
On Mon, Nov 7, 2022 at 3:49 PM Jean-Luc Deprez <Je...@gmail.com>
wrote:
> >
> > Not sure what the point is? That git requires signatures for
> > authentication (like many decentralized protocols) while svn was based
> > on client-server-based authentication?
> >
>
> Indeed
>
> This was not related to git at all, is it? It is more about some kind
> > of social engineering to get changes accepted (which are hard to
> > counter for projects on the scale of Linux).
> >
>
> Correct. TBH you don't need the size of the Linux kernel to be susceptible
> to this.
>
> Precise traceability of who wrote which exact portions code isn't of any
> > critical importance in open source projects, authorship is. You have
> > ...
> > whole point of the CLA/Apache Foundation, one of its main goals is to
> > actually to protect individuals.
> >
>
> I guess that's what I aimed to say with "enterprise thinking".
>
> If commit signing is deemed irrelevant, the importance of merge commits
> drops indeed.
>
> Which reduces the "discussion" to, should merge commits still be allowed in
> certain cases or should that always be a rebase no matter the size of the
> incoming work? (aka. linear history)
>
> I guess the one remaining thing that bugs me about the rebase option is
> that I think you loose the link with the PR, which you would get in the
> merge (or squash) commit otherwise.
>
--
Matthew de Detrich
*Aiven Deutschland GmbH*
Immanuelkirchstraße 26, 10405 Berlin
Amtsgericht Charlottenburg, HRB 209739 B
Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
*m:* +491603708037
*w:* aiven.io *e:* matthew.dedetrich@aiven.io
Re: Forcing rebase/squash and merge for PR merged into Pekko
Posted by Jean-Luc Deprez <Je...@gmail.com>.
>
> Not sure what the point is? That git requires signatures for
> authentication (like many decentralized protocols) while svn was based
> on client-server-based authentication?
>
Indeed
This was not related to git at all, is it? It is more about some kind
> of social engineering to get changes accepted (which are hard to
> counter for projects on the scale of Linux).
>
Correct. TBH you don't need the size of the Linux kernel to be susceptible
to this.
Precise traceability of who wrote which exact portions code isn't of any
> critical importance in open source projects, authorship is. You have
> ...
> whole point of the CLA/Apache Foundation, one of its main goals is to
> actually to protect individuals.
>
I guess that's what I aimed to say with "enterprise thinking".
If commit signing is deemed irrelevant, the importance of merge commits
drops indeed.
Which reduces the "discussion" to, should merge commits still be allowed in
certain cases or should that always be a rebase no matter the size of the
incoming work? (aka. linear history)
I guess the one remaining thing that bugs me about the rebase option is
that I think you loose the link with the PR, which you would get in the
merge (or squash) commit otherwise.
Re: Forcing rebase/squash and merge for PR merged into Pekko
Posted by Matthew Benedict de Detrich <ma...@aiven.io.INVALID>.
> Well, not a contradiction at all. Taking "what works" is helped by
placing
some (not all) trust in audit trails/traceability.
> Anyhow, I think in general commit spoofing is not a well lit complication
of using Git, which did not exist with e.g. SVN.
https://eu01.z.antigena.com/l/GnaFdkimCry-aqbohHxEtHbdEtrdWQZKi6yeLnvLsM2Dw6rphNVV7u1cKACbL~F7VEt6Q6xNOJ6o9a0mLF77eGzcgqVcK3DDJ4Rtqj_SeXhVq0bsnuPRMDxktFxV~FJOm6h2nxu6OJb4DqCy6RWfl9bHxXnEx-nM-RAgMwwiB~skqriGbbOHPmEq5t30lzw_84MHmkdPPLZPnojt8l23rr
> And while these guys haven't made many friends in OSS, I think they did
highlight very important risks.
https://eu01.z.antigena.com/l/5UqAwcvQL66zNl8fFeOxusJmUM35w1O4Sw-_LvSAL1a7hr1qBWMND8al-jJJxS1C-SEy5avXu-4n7ZgTfpGS3BgSsErXnSYyrDuHRsTjVrfU4VpClkfSFAQC3BqPLBiXCISpFNLAMUKbmdnHGVBIevUA~buZD852znrZnE1ytNMIB62CI2csovJ_Bs2
> But I will admit, the first doesn't really matter much if you systemically
squash. Rebasing is another story though.
Precise traceability of who wrote which exact portions code isn't of any
critical importance in open source projects, authorship is. You have
projects such as Postgres where people submit .patch files and the
committer who makes the merge request can change the actual code as much as
they want before merging it into the main git branch. Open source projects
are not an enterprise, this level of traceability is unnecessary. If there
is some problem with a piece of code, it's more critical that we can
cleanly revert it/apply fixes rather than knowing precisely who wrote what
which is not really relevant. Likewise for any kind of legal
ramifications of perfect traceability is a non concern since that's the
whole point of the CLA/Apache Foundation, one of its main goals is to
actually to protect individuals.
On Mon, Nov 7, 2022 at 2:27 PM Jean-Luc Deprez <Je...@gmail.com>
wrote:
> >
> > That's not correct AFAIK. Usually, the PR *opener* (not merger) is
> > listed as the git author and Github is listed as the committer. This
> > is a gotcha that bit us before when a PR had to be reworked and
> > recommitted from another person, and then was finally squashed.
> >
>
> Any chance that that behaviour depends on a) if there's one or multiple
> commits, b) one or multiple authors of those commits?
>
> Because your statement doesn't seem to align with my experience on that
> matter. Except when squashing a single commit, which is transferred
> unmodified other than the commit comment.
>
> Following feature update seems to indicate that what I'm saying is not
> complete nonsense.
>
> https://eu01.z.antigena.com/l/ZPKH0brX88pLCsquG6vX0uCynARbqDiwBjc1fy6ZILjBye2RHkhletlC82fl3R63qI~x7oC6OlWwIUwNFcntvOyya1IKlpRq1ffKHkgdA~iSuT6fZGGxBHhzn4fm55lNl1mx3jR6bOtrjwF6euz3xpdUrtC-oe9cWEpAkNI9OIRJpnctetAjdNOcqwxvGQaxyqte4IwJJuDoYa06-GOzgvs2GeXFmn
>
>
> >
> > Unfortunately not, it only testifies that Github created the commit.
> > In the best case (relying on Github's rules that may or may not change
> > in the future), we could say it testifies who the creator of the PR
> > was which still does not say anything about the contents of the commit
> > (or even through which PR it was merged). Most of this information can
> > be accessed through the GH UI but it's not recorded in the commit.
> > It's a common problem when doing code archeology to trace back how and
> > where things have originated...
> >
> >
> It sure seems like there an element of surprise to the matter
>
> https://eu01.z.antigena.com/l/3UV-AVqlA77upaVL7epN_VAhs7aNi~2WS017-RgS3BRZ6H-6M6Eedhy46~pOGc~DCHvj-hUucTPPZKcasNDYVzVRcSK8Rb0f_3YPEZ7NiwjNKqNUGxrax7e9gXPfABXrrO1GMUuGAXggyEDN1i0mqYHB_0W3Bm6L9I
>
>
> >
> > From my experience, OS is often more strict and principled about these
> > things than enterprises which often take whatever works as long as
> > there's some progress ;)
> >
> >
> Well, not a contradiction at all. Taking "what works" is helped by placing
> some (not all) trust in audit trails/traceability.
>
> Anyhow, I think in general commit spoofing is not a well lit complication
> of using Git, which did not exist with e.g. SVN.
>
> https://eu01.z.antigena.com/l/GnaFdkimCry-aqbohHxEtHbdEtrdWQZKi6yeLnvLsM2Dw6rphNVV7u1cKACbL~F7VEt6Q6xNOJ6o9a0mLF77eGzcgqVcK3DDJ4Rtqj_SeXhVq0bsnuPRMDxktFxV~FJOm6h2nxu6OJb4DqCy6RWfl9bHxXnEx-nM-RAgMwwiB~skqriGbbOHPmEq5t30lzw_84MHmkdPPLZPnojt8l23rr
>
> And while these guys haven't made many friends in OSS, I think they did
> highlight very important risks.
>
> https://eu01.z.antigena.com/l/5UqAwcvQL66zNl8fFeOxusJmUM35w1O4Sw-_LvSAL1a7hr1qBWMND8al-jJJxS1C-SEy5avXu-4n7ZgTfpGS3BgSsErXnSYyrDuHRsTjVrfU4VpClkfSFAQC3BqPLBiXCISpFNLAMUKbmdnHGVBIevUA~buZD852znrZnE1ytNMIB62CI2csovJ_Bs2
>
> But I will admit, the first doesn't really matter much if you systemically
> squash. Rebasing is another story though.
>
--
Matthew de Detrich
*Aiven Deutschland GmbH*
Immanuelkirchstraße 26, 10405 Berlin
Amtsgericht Charlottenburg, HRB 209739 B
Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
*m:* +491603708037
*w:* aiven.io *e:* matthew.dedetrich@aiven.io
Re: Forcing rebase/squash and merge for PR merged into Pekko
Posted by Johannes Rudolph <jo...@gmail.com>.
On Mon, Nov 7, 2022 at 2:27 PM Jean-Luc Deprez <Je...@gmail.com> wrote:
> > That's not correct AFAIK. Usually, the PR *opener* (not merger) is
> > listed as the git author and Github is listed as the committer. This
> > is a gotcha that bit us before when a PR had to be reworked and
> > recommitted from another person, and then was finally squashed.
>
> Any chance that that behaviour depends on a) if there's one or multiple
> commits, b) one or multiple authors of those commits?
As of at least a few months ago, it did not matter (but it might have
in the past).
> Following feature update seems to indicate that what I'm saying is not
> complete nonsense.
> https://github.blog/changelog/2022-09-15-git-commit-author-shown-when-squash-merging-a-pull-request/
It's related but maybe not as you think :) In any case, it is not
clearly specified and information can be lost or changed in the
process. Also, the behavior might have changed over time.
In any case, just take the evidence from the pekko commit history.
Consider all of the original Akka commits squashed with most PR
openers not having commit rights. All of those have the original
authors still listed and almost all committers are Github.
> It sure seems like there an element of surprise to the matter
> https://github.com/isaacs/github/issues/1368
This is actually also related to the above blog post. Since the final
author relies on the PR opener and not on the commits at all when
squashing, it is only consistent that Github may rewrite the author to
use an email address it knows from the PR opener instead of the one
creating the commit. It seems at that point (4 years ago) the
committer might have been the merger but that's usually not the case
right now. The added feature now at least shows what email will be
used for the author and allows to choose in case the merger is also
the PR opener (but unrelated to any commits the PR contains).
> Anyhow, I think in general commit spoofing is not a well lit complication
> of using Git, which did not exist with e.g. SVN.
> https://mikegerwitz.com/2012/05/a-git-horror-story-repository-integrity-with-signed-commits
Not sure what the point is? That git requires signatures for
authentication (like many decentralized protocols) while svn was based
on client-server-based authentication?
> And while these guys haven't made many friends in OSS, I think they did
> highlight very important risks.
> https://www.phoronix.com/news/Hypocrite-Commit-Open-Letter
This was not related to git at all, is it? It is more about some kind
of social engineering to get changes accepted (which are hard to
counter for projects on the scale of Linux).
> But I will admit, the first doesn't really matter much if you systemically
> squash. Rebasing is another story though.
- squash rewrites commits giving authorship to the PR without regards
to the authors in the commits themselves (possibly completely changing
the original commits)
- rebase keeps original commits as much as possible (but might change
them as needed for rebasing)
Not sure whether I can say with confidence if one or the other is better...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
For additional commands, e-mail: dev-help@pekko.apache.org
Re: Forcing rebase/squash and merge for PR merged into Pekko
Posted by Jean-Luc Deprez <Je...@gmail.com>.
>
> That's not correct AFAIK. Usually, the PR *opener* (not merger) is
> listed as the git author and Github is listed as the committer. This
> is a gotcha that bit us before when a PR had to be reworked and
> recommitted from another person, and then was finally squashed.
>
Any chance that that behaviour depends on a) if there's one or multiple
commits, b) one or multiple authors of those commits?
Because your statement doesn't seem to align with my experience on that
matter. Except when squashing a single commit, which is transferred
unmodified other than the commit comment.
Following feature update seems to indicate that what I'm saying is not
complete nonsense.
https://github.blog/changelog/2022-09-15-git-commit-author-shown-when-squash-merging-a-pull-request/
>
> Unfortunately not, it only testifies that Github created the commit.
> In the best case (relying on Github's rules that may or may not change
> in the future), we could say it testifies who the creator of the PR
> was which still does not say anything about the contents of the commit
> (or even through which PR it was merged). Most of this information can
> be accessed through the GH UI but it's not recorded in the commit.
> It's a common problem when doing code archeology to trace back how and
> where things have originated...
>
>
It sure seems like there an element of surprise to the matter
https://github.com/isaacs/github/issues/1368
>
> From my experience, OS is often more strict and principled about these
> things than enterprises which often take whatever works as long as
> there's some progress ;)
>
>
Well, not a contradiction at all. Taking "what works" is helped by placing
some (not all) trust in audit trails/traceability.
Anyhow, I think in general commit spoofing is not a well lit complication
of using Git, which did not exist with e.g. SVN.
https://mikegerwitz.com/2012/05/a-git-horror-story-repository-integrity-with-signed-commits
And while these guys haven't made many friends in OSS, I think they did
highlight very important risks.
https://www.phoronix.com/news/Hypocrite-Commit-Open-Letter
But I will admit, the first doesn't really matter much if you systemically
squash. Rebasing is another story though.
Re: Forcing rebase/squash and merge for PR merged into Pekko
Posted by Matthew Benedict de Detrich <ma...@aiven.io.INVALID>.
> Adding `Co-authored-by`, usually works automatically in the Github UI
for squashing but we have also seen instances where the UI was not
working completely correctly, so some care is needed. The "merger"
will only be included in the Git history as the author of a merge
commit (in case merging was used). In case of squash and rebase, the
merger will not be recorded in the history.
Indeed this is correct, github UI now automatically adds a Co-authored-by
in the commit. I personally did not experience cases where it was not
added, maybe Github improved it and/or I didn't hit such cases.
On Mon, 7 Nov 2022, 12:56 Johannes Rudolph, <jo...@gmail.com>
wrote:
> On Mon, Nov 7, 2022 at 12:26 PM Jean-Luc Deprez
> <Je...@gmail.com> wrote:
> > 2. The GH Actor (so merger) is listed a author, which is fair, as the
> > one deciding to make one commit.
>
> That's not correct AFAIK. Usually, the PR *opener* (not merger) is
> listed as the git author and Github is listed as the committer. This
> is a gotcha that bit us before when a PR had to be reworked and
> recommitted from another person, and then was finally squashed.
>
> Adding `Co-authored-by`, usually works automatically in the Github UI
> for squashing but we have also seen instances where the UI was not
> working completely correctly, so some care is needed. The "merger"
> will only be included in the Git history as the author of a merge
> commit (in case merging was used). In case of squash and rebase, the
> merger will not be recorded in the history.
>
> > The GH signature testifies to the identity of the author, who was
> authenticated in GH (yes that make GH a central authority on this front)
>
> Unfortunately not, it only testifies that Github created the commit.
> In the best case (relying on Github's rules that may or may not change
> in the future), we could say it testifies who the creator of the PR
> was which still does not say anything about the contents of the commit
> (or even through which PR it was merged). Most of this information can
> be accessed through the GH UI but it's not recorded in the commit.
> It's a common problem when doing code archeology to trace back how and
> where things have originated...
>
> I still agree that all three modes can be useful and squash is a good
> default because many changes are simple in structure and squash
> simplifies the overhead required to apply simple changes.
>
> > That being said, it's very possible that this is an enterprise mindset
> which doesn't fit an open source project.
>
> From my experience, OS is often more strict and principled about these
> things than enterprises which often take whatever works as long as
> there's some progress ;)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> For additional commands, e-mail: dev-help@pekko.apache.org
>
>
Re: Forcing rebase/squash and merge for PR merged into Pekko
Posted by Johannes Rudolph <jo...@gmail.com>.
On Mon, Nov 7, 2022 at 12:26 PM Jean-Luc Deprez
<Je...@gmail.com> wrote:
> 2. The GH Actor (so merger) is listed a author, which is fair, as the
> one deciding to make one commit.
That's not correct AFAIK. Usually, the PR *opener* (not merger) is
listed as the git author and Github is listed as the committer. This
is a gotcha that bit us before when a PR had to be reworked and
recommitted from another person, and then was finally squashed.
Adding `Co-authored-by`, usually works automatically in the Github UI
for squashing but we have also seen instances where the UI was not
working completely correctly, so some care is needed. The "merger"
will only be included in the Git history as the author of a merge
commit (in case merging was used). In case of squash and rebase, the
merger will not be recorded in the history.
> The GH signature testifies to the identity of the author, who was authenticated in GH (yes that make GH a central authority on this front)
Unfortunately not, it only testifies that Github created the commit.
In the best case (relying on Github's rules that may or may not change
in the future), we could say it testifies who the creator of the PR
was which still does not say anything about the contents of the commit
(or even through which PR it was merged). Most of this information can
be accessed through the GH UI but it's not recorded in the commit.
It's a common problem when doing code archeology to trace back how and
where things have originated...
I still agree that all three modes can be useful and squash is a good
default because many changes are simple in structure and squash
simplifies the overhead required to apply simple changes.
> That being said, it's very possible that this is an enterprise mindset which doesn't fit an open source project.
From my experience, OS is often more strict and principled about these
things than enterprises which often take whatever works as long as
there's some progress ;)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
For additional commands, e-mail: dev-help@pekko.apache.org
Re: Forcing rebase/squash and merge for PR merged into Pekko
Posted by Jean-Luc Deprez <Je...@gmail.com>.
> Merge commits provide no value for projects that are based on Github
Well, the value sits not in the merge commit, they are merely an artifact
of the fact that things evolved separately and rejoined at some point.
Which also allows to track changes that simply reconciled the separate
evolution. Saying that there's no information there, is in part denying
history.
> It makes the usability of cherry picking/merging branches a lot less
trivial
I'm surely not arguing to keep all temp commits, but instead, have well
defined commits that sometimes are allowed to have existed on a branch. But
very case dependent.
E.g. the scala 3 work for pekko-http, seems to be something were seeing the
two things evolve apart from each other makes sense.
> If we want signatures we cannot allow squashing, so 2. seems a bit
inconsistent...
It seems but it isn't. It means that the merger assessed that there's no
need/value to maintain the separate commits, so they're allowed to be
squashed into 1 commit.
At that point, GH does the following:
1. GH is listed as Git committer and the GH signature is applied
2. The GH Actor (so merger) is listed a author, which is fair, as the
one deciding to make one commit.
The GH signature testifies to the identity of the author, who was
authenticated in GH (yes that make GH a central authority on this front)
3. Other authors will be listed with the Co-authored-by comment tag.
Which is fair, given that it's about attribution. Just like the Git
author tag is.
These elements establish the same or similar committer identity trust as
locally signed commits (or rebases) do.
To sum up:
1. I don't think there's a one size fits all approach, any of squash,
rebase and merge can make sense.
2. I do think commit signatures are important, because the signer is the
one that declared things to be trustworthy.
3. Because of 2, GH UI rebase is problematic
Because of point 2, using squash and rebase should of course be done with
care and you can certainly argue that contributors are required to make a
set of clean commits before they can be merged.
That being said, it's very possible that this is an enterprise mindset
which doesn't fit an open source project.
Re: Forcing rebase/squash and merge for PR merged into Pekko
Posted by Johannes Rudolph <jo...@gmail.com>.
On Mon, Nov 7, 2022 at 9:53 AM Jean-Luc Deprez <Je...@gmail.com> wrote:
> My personal stance:
>
> 1. No, because it's not the Git way and because of #4
> 2. Allowed yes, but only when it makes sense, it should not be the
> default way.
> 3. No, because #4.
> Local rebasing (and squashing in the process) is still possible. But
> that will have clear committer tags and signatures.
> 4. Yes, traceability of changes has relevance in this modern day and age.
If we want signatures we cannot allow squashing, so 2. seems a bit
inconsistent...
I argued both ways in the ticket but one very important practical
consideration is that requiring signatures means that we
1. require contributors to contribute full commits (because there can
only be one signature per commit)
2. commits that would logically stand alone cannot be authored by
multiple persons (the result of a squash)
1. is often a problem in practice because it means that we require
that all fixes to PRs have to be ultimately done by the original
contributors. Often this leads to stalled contributions because a
contributor couldn't be bothered to do the final minor fixups
necessary for merging. The only way to resolve that by merging would
be to add additional fixup commits which makes dealing with the
history later on difficult.
The trade-off is basically between using commits as standalone changes
in terms of functionality or as standalone pieces of ownership. I much
prefer the first notion.
Johannes
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
For additional commands, e-mail: dev-help@pekko.apache.org
Re: Forcing rebase/squash and merge for PR merged into Pekko
Posted by Matthew Benedict de Detrich <ma...@aiven.io.INVALID>.
So I am a very strong proponent for linear history, here are my arguments
1. Merge commits provide no value for projects that are based on Github.
Having merge commits make perfect sense in the original context they were
used, which is sending patches on mailing lists (Linux/Postgres style
development). In this case its very hard to figure out who specifically
merged a pull request, this is a non issue with github. While I understand
the "branches/commits are cheap" philosophy behind git, they need to
provide value. Merge commits for mailing list style project development
does provide value, for projects on github it's just noise.
2. It makes the usability of cherry picking/merging branches a lot less
trivial. This is also going to be a concern for Pekko, we are going to have
multiple release branches and there are going to be cases of needing to
cherry pick between them.
3. The current pre Pekko Akka codebase also had linear history. For the
sakes of consistency unless there is a very strong argument I don't see why
we should change such a thing.
4. In the past, rebasing/squashing was foreign to a lot of git users which
in my view was probably the strongest reason for merge commits. Users had
to manually do the rebasing themselves and force push onto a branch (if we
go back far enough force-push-with-lease didn't even exist which made the
flow even more dangerous). However ever since github added the "squash" and
"rebase" buttons on the UI this has become a non concern.
5. Also, add https://www.aubm.net/posts/the-case-of-a-git-linear-history/
onto that
On Mon, Nov 7, 2022 at 9:53 AM Jean-Luc Deprez <Je...@gmail.com>
wrote:
> As per discussion up to here:
> https://github.com/apache/incubator-pekko/pull/8#discussion_r1014136294
>
> It looks like there's a need for agreement of "what the right way of
> working" is.
>
> I'm not going to repeat everything what was said there, but please do
> review. The gist is the following.
>
>
> 1. Should there be a strive for linear history?
> 2. Should squashing be used to achieve that linear history?
> 3. Should GitHub UI rebasing be allowed?
> Noting that that one destroys commit signatures.
> 4. Should commit signatures be used?
>
>
> My personal stance:
>
> 1. No, because it's not the Git way and because of #4
> 2. Allowed yes, but only when it makes sense, it should not be the
> default way.
> 3. No, because #4.
> Local rebasing (and squashing in the process) is still possible. But
> that will have clear committer tags and signatures.
> 4. Yes, traceability of changes has relevance in this modern day and
> age.
>
>
>
>
>
> On Thu, Nov 3, 2022 at 9:35 PM Matthew Benedict de Detrich
> <ma...@aiven.io.invalid> wrote:
>
> > Is now fixed thanks to https://github.com/apache/incubator-pekko/pull/8
> >
> > --
> > Matthew de Detrich
> > Aiven Deutschland GmbH
> > Immanuelkirchstraße 26, 10405 Berlin
> > Amtsgericht Charlottenburg, HRB 209739 B
> >
> > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> > m: +491603708037
> > w: aiven.io e: matthew.dedetrich@aiven.io
> > On 3. Nov 2022 at 17:04 +0100, Matthew Benedict de Detrich <
> > matthew.dedetrich@aiven.io>, wrote:
> > > I just noticed that when
> > https://github.com/apache/incubator-pekko/pull/5 was merged it was done
> > via a merge commit. I think that this is a good time to discuss what
> method
> > of merging we should use. I would stick with rebase/squash and merge
> > because if you look at the git history of Akka you can see that we don’t
> > use merge commits. I just asked a fellow Flink committer how this is done
> > (since Flink also has the same setup, i.e. no merge commits) and
> apparently
> > a PMC member has to directly set it in the GitHub settings.
> > >
> > > @PJ Fanning, if we end up enforcing this on
> > https://github.com/apache/incubator-pekko then I would recommend rebase
> > the current main branch and pushing it to get rid of the merge commit so
> > the git history is clean.
> > >
> > > --
> > > Matthew de Detrich
> > > Aiven Deutschland GmbH
> > > Immanuelkirchstraße 26, 10405 Berlin
> > > Amtsgericht Charlottenburg, HRB 209739 B
> > >
> > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> > > m: +491603708037
> > > w: aiven.io e: matthew.dedetrich@aiven.io
> >
>
--
Matthew de Detrich
*Aiven Deutschland GmbH*
Immanuelkirchstraße 26, 10405 Berlin
Amtsgericht Charlottenburg, HRB 209739 B
Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
*m:* +491603708037
*w:* aiven.io *e:* matthew.dedetrich@aiven.io
Re: Forcing rebase/squash and merge for PR merged into Pekko
Posted by Jean-Luc Deprez <Je...@gmail.com>.
As per discussion up to here:
https://github.com/apache/incubator-pekko/pull/8#discussion_r1014136294
It looks like there's a need for agreement of "what the right way of
working" is.
I'm not going to repeat everything what was said there, but please do
review. The gist is the following.
1. Should there be a strive for linear history?
2. Should squashing be used to achieve that linear history?
3. Should GitHub UI rebasing be allowed?
Noting that that one destroys commit signatures.
4. Should commit signatures be used?
My personal stance:
1. No, because it's not the Git way and because of #4
2. Allowed yes, but only when it makes sense, it should not be the
default way.
3. No, because #4.
Local rebasing (and squashing in the process) is still possible. But
that will have clear committer tags and signatures.
4. Yes, traceability of changes has relevance in this modern day and age.
On Thu, Nov 3, 2022 at 9:35 PM Matthew Benedict de Detrich
<ma...@aiven.io.invalid> wrote:
> Is now fixed thanks to https://github.com/apache/incubator-pekko/pull/8
>
> --
> Matthew de Detrich
> Aiven Deutschland GmbH
> Immanuelkirchstraße 26, 10405 Berlin
> Amtsgericht Charlottenburg, HRB 209739 B
>
> Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> m: +491603708037
> w: aiven.io e: matthew.dedetrich@aiven.io
> On 3. Nov 2022 at 17:04 +0100, Matthew Benedict de Detrich <
> matthew.dedetrich@aiven.io>, wrote:
> > I just noticed that when
> https://github.com/apache/incubator-pekko/pull/5 was merged it was done
> via a merge commit. I think that this is a good time to discuss what method
> of merging we should use. I would stick with rebase/squash and merge
> because if you look at the git history of Akka you can see that we don’t
> use merge commits. I just asked a fellow Flink committer how this is done
> (since Flink also has the same setup, i.e. no merge commits) and apparently
> a PMC member has to directly set it in the GitHub settings.
> >
> > @PJ Fanning, if we end up enforcing this on
> https://github.com/apache/incubator-pekko then I would recommend rebase
> the current main branch and pushing it to get rid of the merge commit so
> the git history is clean.
> >
> > --
> > Matthew de Detrich
> > Aiven Deutschland GmbH
> > Immanuelkirchstraße 26, 10405 Berlin
> > Amtsgericht Charlottenburg, HRB 209739 B
> >
> > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> > m: +491603708037
> > w: aiven.io e: matthew.dedetrich@aiven.io
>
Re: Forcing rebase/squash and merge for PR merged into Pekko
Posted by Matthew Benedict de Detrich <ma...@aiven.io.INVALID>.
Is now fixed thanks to https://github.com/apache/incubator-pekko/pull/8
--
Matthew de Detrich
Aiven Deutschland GmbH
Immanuelkirchstraße 26, 10405 Berlin
Amtsgericht Charlottenburg, HRB 209739 B
Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
m: +491603708037
w: aiven.io e: matthew.dedetrich@aiven.io
On 3. Nov 2022 at 17:04 +0100, Matthew Benedict de Detrich <ma...@aiven.io>, wrote:
> I just noticed that when https://github.com/apache/incubator-pekko/pull/5 was merged it was done via a merge commit. I think that this is a good time to discuss what method of merging we should use. I would stick with rebase/squash and merge because if you look at the git history of Akka you can see that we don’t use merge commits. I just asked a fellow Flink committer how this is done (since Flink also has the same setup, i.e. no merge commits) and apparently a PMC member has to directly set it in the GitHub settings.
>
> @PJ Fanning, if we end up enforcing this on https://github.com/apache/incubator-pekko then I would recommend rebase the current main branch and pushing it to get rid of the merge commit so the git history is clean.
>
> --
> Matthew de Detrich
> Aiven Deutschland GmbH
> Immanuelkirchstraße 26, 10405 Berlin
> Amtsgericht Charlottenburg, HRB 209739 B
>
> Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> m: +491603708037
> w: aiven.io e: matthew.dedetrich@aiven.io