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 guilhermebla...@gmail.com <
guilhermebla...@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 <cmbecke...@gmx.de>
> wrote:
> >
> > On 19.09.2019 at 17:01, guilhermebla...@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
>
>

Reply via email to