Question about merged PR #937

  107232
September 19, 2019 15:01 guilhermeblanco@gmail.com ("guilhermeblanco@gmail.com")
Hi internals!

One of my old PRs to PHP that was claimed to be merged disappeared
from master. However, the upgrade note is still there in master and
7.4beta1.

Here is the PR: https://github.com/php/php-src/pull/937
Here is the commit referencing it:
https://github.com/php/php-src/commit/0adfa03397edcde8cba3bae2032b1f2ef26ea760

Please let me know if there's anything I can do to help.

Regards,

-- 
Guilherme Blanco
SVP Technology at Statflo Inc.
Mobile: +1 647 232 5599
  107233
September 19, 2019 16:58 cmbecker69@gmx.de ("Christoph M. Becker")
On 19.09.2019 at 17:01, guilhermeblanco@gmail.com wrote:
> One of my old PRs to PHP that was claimed to be merged disappeared > from master. However, the upgrade note is still there in master and > 7.4beta1. > > Here is the PR: https://github.com/php/php-src/pull/937 > Here is the commit referencing it: > https://github.com/php/php-src/commit/0adfa03397edcde8cba3bae2032b1f2ef26ea760 > > Please let me know if there's anything I can do to help.
From what I can tell, everything is there. PR #911 has been merged as <http://git.php.net/?p=php-src.git;a=commit;h=094d409b3d34c51f49e0121e5ccfe8b2a717aaf6>, and parts of that PR already with PR #928 as <http://git.php.net/?p=php-src.git;a=commit;h=f48c2327403ce76a870e74f31a069a64dfb711a2>. -- Christoph M. Becker
  107235
September 19, 2019 17:20 guilhermeblanco@gmail.com ("guilhermeblanco@gmail.com")
Thanks for the clarification Christoph!
Somehow I couldn't see it when looking for the commit hash. Sorry for
the disturbance in the list here.

PS: I find it funny that even though I'm the original author of the
code, I don't show as a contributor in any statistics.
It'd be a shame to not be considered as a valid voter for "lack of
recent contribution" to the language.

Cheers,


On Thu, Sep 19, 2019 at 12:58 PM Christoph M. Becker <cmbecker69@gmx.de> wrote:
> > On 19.09.2019 at 17:01, guilhermeblanco@gmail.com wrote: > > One of my old PRs to PHP that was claimed to be merged disappeared > > from master. However, the upgrade note is still there in master and > > 7.4beta1. > > > > Here is the PR: https://github.com/php/php-src/pull/937 > > Here is the commit referencing it: > > https://github.com/php/php-src/commit/0adfa03397edcde8cba3bae2032b1f2ef26ea760 > > > > Please let me know if there's anything I can do to help. > > From what I can tell, everything is there. PR #911 has been merged as > <http://git.php.net/?p=php-src.git;a=commit;h=094d409b3d34c51f49e0121e5ccfe8b2a717aaf6>, > and parts of that PR already with PR #928 as > <http://git.php.net/?p=php-src.git;a=commit;h=f48c2327403ce76a870e74f31a069a64dfb711a2>. > > -- > Christoph M. Becker
-- Guilherme Blanco SVP Technology at Statflo Inc. Mobile: +1 647 232 5599
  107244
September 19, 2019 22:49 drealecs@gmail.com (=?UTF-8?Q?Alexandru_P=C4=83tr=C4=83nescu?=)
Hi Guilherme,

That is what is happening when squashing commits during merge.

I noticed this also few months ago but didn't mentioned it as I though this
is one of the usual flows.
I quickly searched it now and found it here:
https://wiki.php.net/vcs/gitworkflow: "Additionally, the history of pull
requests often requires cleanup. For most pull requests, all commits can be
squashed into one."

It could be considered a good practice to not pollute git history with a
lot of small commits as it would hinder analyzing it later.
On the other hand I quite like (and promote) doing small incremental steps
during a PR for multiple reasons that I can highlight if needed.

Analyzing git history could be simplified by using --first-parent when one
would not want to go in details on second parent of a merge commit with
individual detailed commits.
Also, there is no noticeable git performance improvements when using squash.

One of the advantages here would be that author would see his name in
contributors of a file or on repository level and be proud of it.
This is an important factor especially in open source software as otherwise
it could leave a bitter taste that you are not fully recognized as
contributor in git's history and might decrease the chance to future
contributions.

Would it be up for discussion to define the way to merge pull requests in
order to avoid squashing merges by a different author? Has this issue been
discussed before?
The mention that "the history of pull requests often requires cleanup" is
not clearly defined. I would not agree that PR-937
https://github.com/php/php-src/pull/937/commits or  PR-911
https://github.com/php/php-src/pull/911/commits required squashing.
As a simple solution, if squashing is required it should be done by the
original author, before merging.

Regards,
Alex


On Thu, Sep 19, 2019 at 8:20 PM guilhermeblanco@gmail.com <
guilhermeblanco@gmail.com> wrote:

> Thanks for the clarification Christoph! > Somehow I couldn't see it when looking for the commit hash. Sorry for > the disturbance in the list here. > > PS: I find it funny that even though I'm the original author of the > code, I don't show as a contributor in any statistics. > It'd be a shame to not be considered as a valid voter for "lack of > recent contribution" to the language. > > Cheers, > > > On Thu, Sep 19, 2019 at 12:58 PM Christoph M. Becker <cmbecker69@gmx.de> > wrote: > > > > On 19.09.2019 at 17:01, guilhermeblanco@gmail.com wrote: > > > One of my old PRs to PHP that was claimed to be merged disappeared > > > from master. However, the upgrade note is still there in master and > > > 7.4beta1. > > > > > > Here is the PR: https://github.com/php/php-src/pull/937 > > > Here is the commit referencing it: > > > > https://github.com/php/php-src/commit/0adfa03397edcde8cba3bae2032b1f2ef26ea760 > > > > > > Please let me know if there's anything I can do to help. > > > > From what I can tell, everything is there. PR #911 has been merged as > > < > http://git.php.net/?p=php-src.git;a=commit;h=094d409b3d34c51f49e0121e5ccfe8b2a717aaf6 > >, > > and parts of that PR already with PR #928 as > > < > http://git.php.net/?p=php-src.git;a=commit;h=f48c2327403ce76a870e74f31a069a64dfb711a2 > >. > > > > -- > > Christoph M. Becker > > > > -- > Guilherme Blanco > SVP Technology at Statflo Inc. > Mobile: +1 647 232 5599 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
  107252
September 20, 2019 07:36 nikita.ppv@gmail.com (Nikita Popov)
On Fri, Sep 20, 2019 at 12:50 AM Alexandru Pătrănescu <drealecs@gmail.com>
wrote:

> Hi Guilherme, > > That is what is happening when squashing commits during merge. > > I noticed this also few months ago but didn't mentioned it as I though this > is one of the usual flows. > I quickly searched it now and found it here: > https://wiki.php.net/vcs/gitworkflow: "Additionally, the history of pull > requests often requires cleanup. For most pull requests, all commits can be > squashed into one." > > It could be considered a good practice to not pollute git history with a > lot of small commits as it would hinder analyzing it later. > On the other hand I quite like (and promote) doing small incremental steps > during a PR for multiple reasons that I can highlight if needed. > > Analyzing git history could be simplified by using --first-parent when one > would not want to go in details on second parent of a merge commit with > individual detailed commits. > Also, there is no noticeable git performance improvements when using > squash. > > One of the advantages here would be that author would see his name in > contributors of a file or on repository level and be proud of it. > This is an important factor especially in open source software as otherwise > it could leave a bitter taste that you are not fully recognized as > contributor in git's history and might decrease the chance to future > contributions. > > Would it be up for discussion to define the way to merge pull requests in > order to avoid squashing merges by a different author? Has this issue been > discussed before? > The mention that "the history of pull requests often requires cleanup" is > not clearly defined. I would not agree that PR-937 > https://github.com/php/php-src/pull/937/commits or PR-911 > https://github.com/php/php-src/pull/911/commits required squashing. > As a simple solution, if squashing is required it should be done by the > original author, before merging. > > Regards, > Alex >
Git has separate notions of "author" and "committer". The author is preserved during squashing, and the author is what is relevant for contribution statistics on GitHub. If the author is preserved but the user doesn't show up as a contributor, that's likely due to a missing mail mapping between the email address and the GitHub account. Nikita
> On Thu, Sep 19, 2019 at 8:20 PM guilhermeblanco@gmail.com < > guilhermeblanco@gmail.com> wrote: > > > Thanks for the clarification Christoph! > > Somehow I couldn't see it when looking for the commit hash. Sorry for > > the disturbance in the list here. > > > > PS: I find it funny that even though I'm the original author of the > > code, I don't show as a contributor in any statistics. > > It'd be a shame to not be considered as a valid voter for "lack of > > recent contribution" to the language. > > > > Cheers, > > > > > > On Thu, Sep 19, 2019 at 12:58 PM Christoph M. Becker <cmbecker69@gmx.de> > > wrote: > > > > > > On 19.09.2019 at 17:01, guilhermeblanco@gmail.com wrote: > > > > One of my old PRs to PHP that was claimed to be merged disappeared > > > > from master. However, the upgrade note is still there in master and > > > > 7.4beta1. > > > > > > > > Here is the PR: https://github.com/php/php-src/pull/937 > > > > Here is the commit referencing it: > > > > > > > https://github.com/php/php-src/commit/0adfa03397edcde8cba3bae2032b1f2ef26ea760 > > > > > > > > Please let me know if there's anything I can do to help. > > > > > > From what I can tell, everything is there. PR #911 has been merged as > > > < > > > http://git.php.net/?p=php-src.git;a=commit;h=094d409b3d34c51f49e0121e5ccfe8b2a717aaf6 > > >, > > > and parts of that PR already with PR #928 as > > > < > > > http://git.php.net/?p=php-src.git;a=commit;h=f48c2327403ce76a870e74f31a069a64dfb711a2 > > >. > > > > > > -- > > > Christoph M. Becker > > > > > > > > -- > > Guilherme Blanco > > SVP Technology at Statflo Inc. > > Mobile: +1 647 232 5599 > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > >
  107255
September 20, 2019 08:56 drealecs@gmail.com (=?UTF-8?Q?Alexandru_P=C4=83tr=C4=83nescu?=)
Hi Nikita,

Yes, you are right that the author (and not the committer) is the one taken
in considerations for git blame and contributor display. Committer is just
technical and related to who created/recreated a commit.

But, unfortunately, you are wrong in believing that the author is preserved
during merging with squash. A squash merge is similar with a normal commit,
it has a single parent and it does not relate with the original commits in
the git's commit graph.
I can help with us making a quick test to demonstrate this.

Alex

On Fri, Sep 20, 2019 at 10:36 AM Nikita Popov ppv@gmail.com> wrote:

> On Fri, Sep 20, 2019 at 12:50 AM Alexandru Pătrănescu <drealecs@gmail.com> > wrote: > >> Hi Guilherme, >> >> That is what is happening when squashing commits during merge. >> >> I noticed this also few months ago but didn't mentioned it as I though >> this >> is one of the usual flows. >> I quickly searched it now and found it here: >> https://wiki.php.net/vcs/gitworkflow: "Additionally, the history of pull >> requests often requires cleanup. For most pull requests, all commits can >> be >> squashed into one." >> >> It could be considered a good practice to not pollute git history with a >> lot of small commits as it would hinder analyzing it later. >> On the other hand I quite like (and promote) doing small incremental steps >> during a PR for multiple reasons that I can highlight if needed. >> >> Analyzing git history could be simplified by using --first-parent when one >> would not want to go in details on second parent of a merge commit with >> individual detailed commits. >> Also, there is no noticeable git performance improvements when using >> squash. >> >> One of the advantages here would be that author would see his name in >> contributors of a file or on repository level and be proud of it. >> This is an important factor especially in open source software as >> otherwise >> it could leave a bitter taste that you are not fully recognized as >> contributor in git's history and might decrease the chance to future >> contributions. >> >> Would it be up for discussion to define the way to merge pull requests in >> order to avoid squashing merges by a different author? Has this issue been >> discussed before? >> The mention that "the history of pull requests often requires cleanup" is >> not clearly defined. I would not agree that PR-937 >> https://github.com/php/php-src/pull/937/commits or PR-911 >> https://github.com/php/php-src/pull/911/commits required squashing. >> As a simple solution, if squashing is required it should be done by the >> original author, before merging. >> >> Regards, >> Alex >> > > Git has separate notions of "author" and "committer". The author is > preserved during squashing, and the author is what is relevant for > contribution statistics on GitHub. If the author is preserved but the user > doesn't show up as a contributor, that's likely due to a missing mail > mapping between the email address and the GitHub account. > > Nikita > > >> On Thu, Sep 19, 2019 at 8:20 PM guilhermeblanco@gmail.com < >> guilhermeblanco@gmail.com> wrote: >> >> > Thanks for the clarification Christoph! >> > Somehow I couldn't see it when looking for the commit hash. Sorry for >> > the disturbance in the list here. >> > >> > PS: I find it funny that even though I'm the original author of the >> > code, I don't show as a contributor in any statistics. >> > It'd be a shame to not be considered as a valid voter for "lack of >> > recent contribution" to the language. >> > >> > Cheers, >> > >> > >> > On Thu, Sep 19, 2019 at 12:58 PM Christoph M. Becker <cmbecker69@gmx.de >> > >> > wrote: >> > > >> > > On 19.09.2019 at 17:01, guilhermeblanco@gmail.com wrote: >> > > > One of my old PRs to PHP that was claimed to be merged disappeared >> > > > from master. However, the upgrade note is still there in master and >> > > > 7.4beta1. >> > > > >> > > > Here is the PR: https://github.com/php/php-src/pull/937 >> > > > Here is the commit referencing it: >> > > > >> > >> https://github.com/php/php-src/commit/0adfa03397edcde8cba3bae2032b1f2ef26ea760 >> > > > >> > > > Please let me know if there's anything I can do to help. >> > > >> > > From what I can tell, everything is there. PR #911 has been merged as >> > > < >> > >> http://git.php.net/?p=php-src.git;a=commit;h=094d409b3d34c51f49e0121e5ccfe8b2a717aaf6 >> > >, >> > > and parts of that PR already with PR #928 as >> > > < >> > >> http://git.php.net/?p=php-src.git;a=commit;h=f48c2327403ce76a870e74f31a069a64dfb711a2 >> > >. >> > > >> > > -- >> > > Christoph M. Becker >> > >> > >> > >> > -- >> > Guilherme Blanco >> > SVP Technology at Statflo Inc. >> > Mobile: +1 647 232 5599 >> > >> > -- >> > PHP Internals - PHP Runtime Development Mailing List >> > To unsubscribe, visit: http://www.php.net/unsub.php >> > >> > >> >
  107259
September 20, 2019 09:22 drealecs@gmail.com (=?UTF-8?Q?Alexandru_P=C4=83tr=C4=83nescu?=)
I was quick to write an answer and forgot to search for a more detailed
explanation online, being busy with some other work tasks.
Github explains it here:
https://help.github.com/en/articles/about-merge-methods-on-github

Before enabling squashing commits, consider these disadvantages:
> > - You lose information about when specific changes were originally > made and who authored the squashed commits. > > Alex
On Fri, Sep 20, 2019 at 11:56 AM Alexandru Pătrănescu <drealecs@gmail.com> wrote:
> Hi Nikita, > > Yes, you are right that the author (and not the committer) is the one > taken in considerations for git blame and contributor display. Committer is > just technical and related to who created/recreated a commit. > > But, unfortunately, you are wrong in believing that the author is > preserved during merging with squash. A squash merge is similar with a > normal commit, it has a single parent and it does not relate with the > original commits in the git's commit graph. > I can help with us making a quick test to demonstrate this. > > Alex > > On Fri, Sep 20, 2019 at 10:36 AM Nikita Popov ppv@gmail.com> > wrote: > >> On Fri, Sep 20, 2019 at 12:50 AM Alexandru Pătrănescu <drealecs@gmail.com> >> wrote: >> >>> Hi Guilherme, >>> >>> That is what is happening when squashing commits during merge. >>> >>> I noticed this also few months ago but didn't mentioned it as I though >>> this >>> is one of the usual flows. >>> I quickly searched it now and found it here: >>> https://wiki.php.net/vcs/gitworkflow: "Additionally, the history of pull >>> requests often requires cleanup. For most pull requests, all commits can >>> be >>> squashed into one." >>> >>> It could be considered a good practice to not pollute git history with a >>> lot of small commits as it would hinder analyzing it later. >>> On the other hand I quite like (and promote) doing small incremental >>> steps >>> during a PR for multiple reasons that I can highlight if needed. >>> >>> Analyzing git history could be simplified by using --first-parent when >>> one >>> would not want to go in details on second parent of a merge commit with >>> individual detailed commits. >>> Also, there is no noticeable git performance improvements when using >>> squash. >>> >>> One of the advantages here would be that author would see his name in >>> contributors of a file or on repository level and be proud of it. >>> This is an important factor especially in open source software as >>> otherwise >>> it could leave a bitter taste that you are not fully recognized as >>> contributor in git's history and might decrease the chance to future >>> contributions. >>> >>> Would it be up for discussion to define the way to merge pull requests in >>> order to avoid squashing merges by a different author? Has this issue >>> been >>> discussed before? >>> The mention that "the history of pull requests often requires cleanup" is >>> not clearly defined. I would not agree that PR-937 >>> https://github.com/php/php-src/pull/937/commits or PR-911 >>> https://github.com/php/php-src/pull/911/commits required squashing. >>> As a simple solution, if squashing is required it should be done by the >>> original author, before merging. >>> >>> Regards, >>> Alex >>> >> >> Git has separate notions of "author" and "committer". The author is >> preserved during squashing, and the author is what is relevant for >> contribution statistics on GitHub. If the author is preserved but the user >> doesn't show up as a contributor, that's likely due to a missing mail >> mapping between the email address and the GitHub account. >> >> Nikita >> >> >>> On Thu, Sep 19, 2019 at 8:20 PM guilhermeblanco@gmail.com < >>> guilhermeblanco@gmail.com> wrote: >>> >>> > Thanks for the clarification Christoph! >>> > Somehow I couldn't see it when looking for the commit hash. Sorry for >>> > the disturbance in the list here. >>> > >>> > PS: I find it funny that even though I'm the original author of the >>> > code, I don't show as a contributor in any statistics. >>> > It'd be a shame to not be considered as a valid voter for "lack of >>> > recent contribution" to the language. >>> > >>> > Cheers, >>> > >>> > >>> > On Thu, Sep 19, 2019 at 12:58 PM Christoph M. Becker < >>> cmbecker69@gmx.de> >>> > wrote: >>> > > >>> > > On 19.09.2019 at 17:01, guilhermeblanco@gmail.com wrote: >>> > > > One of my old PRs to PHP that was claimed to be merged disappeared >>> > > > from master. However, the upgrade note is still there in master and >>> > > > 7.4beta1. >>> > > > >>> > > > Here is the PR: https://github.com/php/php-src/pull/937 >>> > > > Here is the commit referencing it: >>> > > > >>> > >>> https://github.com/php/php-src/commit/0adfa03397edcde8cba3bae2032b1f2ef26ea760 >>> > > > >>> > > > Please let me know if there's anything I can do to help. >>> > > >>> > > From what I can tell, everything is there. PR #911 has been merged >>> as >>> > > < >>> > >>> http://git.php.net/?p=php-src.git;a=commit;h=094d409b3d34c51f49e0121e5ccfe8b2a717aaf6 >>> > >, >>> > > and parts of that PR already with PR #928 as >>> > > < >>> > >>> http://git.php.net/?p=php-src.git;a=commit;h=f48c2327403ce76a870e74f31a069a64dfb711a2 >>> > >. >>> > > >>> > > -- >>> > > Christoph M. Becker >>> > >>> > >>> > >>> > -- >>> > Guilherme Blanco >>> > SVP Technology at Statflo Inc. >>> > Mobile: +1 647 232 5599 >>> > >>> > -- >>> > PHP Internals - PHP Runtime Development Mailing List >>> > To unsubscribe, visit: http://www.php.net/unsub.php >>> > >>> > >>> >>
  107262
September 20, 2019 10:06 cmbecker69@gmx.de ("Christoph M. Becker")
On 20.09.2019 at 11:22, Alexandru Pătrănescu wrote:

> I was quick to write an answer and forgot to search for a more detailed > explanation online, being busy with some other work tasks. > Github explains it here: > https://help.github.com/en/articles/about-merge-methods-on-github > > Before enabling squashing commits, consider these disadvantages: >> >> - You lose information about when specific changes were originally >> made and who authored the squashed commits.
<http://git.php.net/?p=php-src.git;a=commit;h=8326ef5519acb4dfcdcd3f059ee599d9e0faf174> has just been squashed by me, and still has the proper author information. -- Christoph M. Becker
  107263
September 20, 2019 10:35 drealecs@gmail.com (=?UTF-8?Q?Alexandru_P=C4=83tr=C4=83nescu?=)
Hi Christoph,
Was this squash done during merging of a github pull request?

On Fri, Sep 20, 2019 at 1:06 PM Christoph M. Becker <cmbecker69@gmx.de>
wrote:

> On 20.09.2019 at 11:22, Alexandru Pătrănescu wrote: > > > I was quick to write an answer and forgot to search for a more detailed > > explanation online, being busy with some other work tasks. > > Github explains it here: > > https://help.github.com/en/articles/about-merge-methods-on-github > > > > Before enabling squashing commits, consider these disadvantages: > >> > >> - You lose information about when specific changes were originally > >> made and who authored the squashed commits. > > < > http://git.php.net/?p=php-src.git;a=commit;h=8326ef5519acb4dfcdcd3f059ee599d9e0faf174 > > > has just been squashed by me, and still has the proper author information.. > > -- > Christoph M. Becker >
  107264
September 20, 2019 10:40 cmbecker69@gmx.de ("Christoph M. Becker")
On 20.09.2019 at 12:35, Alexandru Pătrănescu wrote:

> Was this squash done during merging of a github pull request?
Yes, it was when applying <https://github.com/php/php-src/pull/4621>. I didn't use the Github UI, though. -- Christoph M. Becker
  107265
September 20, 2019 10:59 drealecs@gmail.com (=?UTF-8?Q?Alexandru_P=C4=83tr=C4=83nescu?=)
Can you let us know what you used as it's doing the job well :)
CLI git merge or another UI; which one?

I'm also curious what will happen if there would be two authors on the same
branch/pull request.
Is it interactive or pre-configured to use author of the first commit, last
commit, most of the commits?


On Fri, Sep 20, 2019 at 1:40 PM Christoph M. Becker <cmbecker69@gmx.de>
wrote:

> On 20.09.2019 at 12:35, Alexandru Pătrănescu wrote: > > > Was this squash done during merging of a github pull request? > > Yes, it was when applying <https://github.com/php/php-src/pull/4621>. I > didn't use the Github UI, though. > > -- > Christoph M. Becker >
  107285
September 22, 2019 12:02 cmbecker69@gmx.de ("Christoph M. Becker")
On 20.09.2019 at 12:59, Alexandru Pătrănescu wrote:

> Can you let us know what you used as it's doing the job well :) > CLI git merge or another UI; which one?
I'm usually using TortoiseGit, but basically I'm doing git rebase -i HEAD~
> I'm also curious what will happen if there would be two authors on the same > branch/pull request. > Is it interactive or pre-configured to use author of the first commit, last > commit, most of the commits?
In this case I likely would not squash commits of different authors. An alternative would be to append the following to the commit message: Co-authored-by: name <name@example.com> -- Christoph M. Becker
  107339
September 27, 2019 09:25 drealecs@gmail.com (=?UTF-8?Q?Alexandru_P=C4=83tr=C4=83nescu?=)
Hi Christoph,

The method you described looks great.
Squashing with rebase interactive works fine, with choosing what commits to
keep and what commits to squash into the kept ones.
This can be done by merger or author.

Merging a pull request with squashing in github will set the author's
commit to the person who merge it.
The same things happens with *git merge --squash *

If you agree, what would be the best way to propagate this information so
that everyone use this method, when squashing is needed?

Regards,
Alex


On Sun, Sep 22, 2019 at 3:03 PM Christoph M. Becker <cmbecker69@gmx.de>
wrote:

> On 20.09.2019 at 12:59, Alexandru Pătrănescu wrote: > > > Can you let us know what you used as it's doing the job well :) > > CLI git merge or another UI; which one? > > I'm usually using TortoiseGit, but basically I'm doing > > git rebase -i HEAD~ > > > I'm also curious what will happen if there would be two authors on the > same > > branch/pull request. > > Is it interactive or pre-configured to use author of the first commit, > last > > commit, most of the commits? > > In this case I likely would not squash commits of different authors. An > alternative would be to append the following to the commit message: > > Co-authored-by: name <name@example.com> > > -- > Christoph M. Becker >
  107340
September 27, 2019 09:40 cmbecker69@gmx.de ("Christoph M. Becker")
On 27.09.2019 at 11:25, Alexandru Pătrănescu wrote:

> The method you described looks great. > Squashing with rebase interactive works fine, with choosing what commits to > keep and what commits to squash into the kept ones. > This can be done by merger or author. > > Merging a pull request with squashing in github will set the author's > commit to the person who merge it. > The same things happens with *git merge --squash * > > If you agree, what would be the best way to propagate this information so > that everyone use this method, when squashing is needed?
I'm not sure if any commit actually removed the author information. <https://github.com/php/php-src/commit/0adfa03397edcde8cba3bae2032b1f2ef26ea760> certainly didn't, since this commit was not the actual merge, but rather NEWS and UPGRADING information related to that PR. So, where is the problem? :) Regards, Christoph
  107256
September 20, 2019 08:59 cmbecker69@gmx.de ("Christoph M. Becker")
On 19.09.2019 at 19:20, guilhermeblanco@gmail.com wrote:

> Thanks for the clarification Christoph! > Somehow I couldn't see it when looking for the commit hash. Sorry for > the disturbance in the list here. > > PS: I find it funny that even though I'm the original author of the > code, I don't show as a contributor in any statistics. > It'd be a shame to not be considered as a valid voter for "lack of > recent contribution" to the language.
>git log --author=Blanco --pretty=oneline
4498d34aeaadcbc2ab64b9c0f40f336bf363b2d6 Check interface/trait extension for internal classes 8c81d80e10e0f189307fc8ff4a8fb34bd0cb1fcb Made ZEND_ACC_TRAIT a saner value d51fb69c0125a144cacb8c59df89fea3f8ae7f4b Removed parsing support traits to have extends and implements. f48c2327403ce76a870e74f31a069a64dfb711a2 Decoupled class declaration statement into more granular pieces. 094d409b3d34c51f49e0121e5ccfe8b2a717aaf6 Removed ZEND_ACC_FINAL_CLASS which is unnecessary. This also fixed some currently defined classes as final which were just not being considered as such before. Looks good. :) -- Christoph M. Becker