Hi Jark,

Thanks for starting this discussion. Personally I also love the "squash and 
merge" button. It's very convenient.

Regarding to the email address "noreply", it seems that there are two cases:
- The email address in the original commit is already "noreply". In this case, 
this issue will still exist even if the PR is merged via command line, e.g. [1].
- The email address in the original commit is correct and it becomes "noreply" 
when merged via web page button because the author has not correctly set the 
commit email address[2] in his personal github setting, e.g.[3]. In this case, 
it's indeed a problem. However, I have checked that there are only 75 such kind 
of commits out of 5375 commits since Jan 1, 2019. So maybe it's acceptable 
compared to the benefits we could gain.

Regards,
Dian

[1] 
https://github.com/apache/flink/commit/c4db7052c78d6b8204170e17a80a2416fa760523 
<https://github.com/apache/flink/commit/c4db7052c78d6b8204170e17a80a2416fa760523>
[2] 
https://help.github.com/en/github/setting-up-and-managing-your-github-user-account/adding-an-email-address-to-your-github-account
 
<https://help.github.com/en/github/setting-up-and-managing-your-github-user-account/adding-an-email-address-to-your-github-account>
[3] 
https://github.com/apache/flink/commit/9b5232d79a945607a83b02b0025b3206b06c27bd 
<https://github.com/apache/flink/commit/9b5232d79a945607a83b02b0025b3206b06c27bd>
> 在 2020年3月6日,下午12:18,Jark Wu <imj...@gmail.com> 写道:
> 
> Hi Stephan,
> 
>> noreply email address.
> I investigated this and found some x...@users.noreply.github.com address. I
> think that's because they enabled "kepp email addresses private" on GitHub
> [1].
> 
>> Don't most PRs consist anyways of multiple commits where we want to
> preserve "refactor" and "feature" differentiation in the history, rather
> than squash everything?
> For multiple commits, GitHub provides another button called "rebase and
> merge" which is mentioned by Piotr. But I usually operate in local if want
> to preserve multiple commits.
> 
> It seems that GitHub is fixing it in 24 hours:
> https://twitter.com/yadong_xie/status/1235554461256302593
> 
> Best,
> Jark
> 
> [1]:
> https://help.github.com/en/github/setting-up-and-managing-your-github-user-account/setting-your-commit-email-address
> 
> On Fri, 6 Mar 2020 at 10:05, Jingsong Li <jingsongl...@gmail.com> wrote:
> 
>> Hi,
>> 
>> I agree with Jark. The tool is useful. If there are some problem, I think
>> we can reach an agreement to form certain terms?
>> 
>> Github provides:
>> - "rebase and merge" keep all commits.
>> - "squash and merge" squash all commits to one commits, pull request
>> authors used to be multiple commits, like "address comments", "Fix
>> comments", "Fix checkstyle". I think we can help authors to squash these
>> useless commits.
>> 
>> Best,
>> Jingsong Lee
>> 
>> On Fri, Mar 6, 2020 at 4:46 AM Matthias J. Sax <mj...@apache.org> wrote:
>> 
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA512
>>> 
>>> Seems, this will be fixed today:
>>> 
>>> https://twitter.com/natfriedman/status/1235613840659767298?s=19
>>> 
>>> 
>>> - -Matthias
>>> 
>>> On 3/5/20 8:37 AM, Stephan Ewen wrote:
>>>> It looks like this feature still messes up email addresses, for
>>>> example if you do a "git log | grep noreply" in the repo.
>>>> 
>>>> Don't most PRs consist anyways of multiple commits where we want
>>>> to preserve "refactor" and "feature" differentiation in the
>>>> history, rather than squash everything?
>>>> 
>>>> On Thu, Mar 5, 2020 at 4:54 PM Piotr Nowojski <pi...@ververica.com>
>>>> wrote:
>>>> 
>>>>> Hi,
>>>>> 
>>>>> If it’s really not preserving ownership (I didn’t notice the
>>>>> problem before), +1 for removing “squash and merge”.
>>>>> 
>>>>> However -1 for removing “rebase and merge”. I didn’t see any
>>>>> issues with it and I’m using it constantly.
>>>>> 
>>>>> Piotrek
>>>>> 
>>>>>> On 5 Mar 2020, at 16:40, Jark Wu <imj...@gmail.com> wrote:
>>>>>> 
>>>>>> Hi all,
>>>>>> 
>>>>>> Thanks for the feedbacks. But I want to clarify the motivation
>>>>>> to disable "Squash and merge" is just because of the
>>>>>> regression/bug of the missing author information. If GitHub
>>>>>> fixes this later, I think it makes sense to bring this button
>>>>>> back.
>>>>>> 
>>>>>> Hi Stephan & Zhijiang,
>>>>>> 
>>>>>> To be honest, I love the "Squash and merge" button and often
>>>>>> use it. It saves me a lot of time to merge PRs, because pulling
>>>>>> and pushing commits
>>>>> in
>>>>>> China is very unstable.
>>>>>> 
>>>>>> I don't think the potential problems you mentioned is a
>>>>>> "problem". For "Squash and merge", - "Merge commits": there is
>>>>>> no "merge" commits, because GitHub will
>>>>> squash
>>>>>> commits and rebase the commit and then add to the master
>>>>>> branch. - "This closes #<pr>" line to track back: when you
>>>>>> click "Squash and merge", it allows you to edit the title and
>>>>>> description, so you can add "This closes #<pr>" message to the
>>>>>> description the same with in the local git. Besides, GitHub
>>>>>> automatically append "(#<pr>)" after the
>>>>> title,
>>>>>> which is also helpful to track.
>>>>>> 
>>>>>> Best, Jark
>>>>>> 
>>>>>> On Thu, 5 Mar 2020 at 23:36, Robert Metzger
>>>>>> <rmetz...@apache.org> wrote:
>>>>>> 
>>>>>>> +1 for disabling this feature for now.
>>>>>>> 
>>>>>>> Thanks a lot for spotting this!
>>>>>>> 
>>>>>>> On Thu, Mar 5, 2020 at 3:54 PM Zhijiang
>>>>>>> <wangzhijiang...@aliyun.com .invalid> wrote:
>>>>>>> 
>>>>>>>> +1 for disabling "Squash and merge" if feasible to do
>>>>>>>> that.
>>>>>>>> 
>>>>>>>> The possible benefit to use this button is for saving some
>>>>>>>> efforts to squash some intermediate "[fixup]" commits
>>>>>>>> during PR review. But it would bring more potential
>>>>>>>> problems as mentioned below, missing author information and
>>>>>>>> message of "This closes #<pr>", etc. Even it might cause
>>>>>>>> unexpected format of long commit content
>>>>> description
>>>>>>>> if not handled carefully in the text box.
>>>>>>>> 
>>>>>>>> Best, Zhijiang
>>>>>>>> 
>>>>>>>> 
>>>>>>>> ------------------------------------------------------------------
>>>>>>>> 
>>>>>>>> 
>>> From:tison <wander4...@gmail.com>
>>>>>>>> Send Time:2020 Mar. 5 (Thu.) 21:34 To:dev
>>>>>>>> <dev@flink.apache.org> Subject:Re: [DISCUSS] Disable
>>>>>>>> "Squash and merge" button for Flink repository on GitHub
>>>>>>>> 
>>>>>>>> Hi Yadong,
>>>>>>>> 
>>>>>>>> Maybe we firstly reach out INFRA team and see the reply
>>>>>>>> from their
>>>>> side.
>>>>>>>> 
>>>>>>>> Since the actual operator is INFRA team, in the dev mailing
>>>>>>>> list we can focus on motivation and wait for the reply.
>>>>>>>> 
>>>>>>>> Best, tison.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Yadong Xie <vthink...@gmail.com> 于2020年3月5日周四 下午9:29写道:
>>>>>>>> 
>>>>>>>>> Hi Jark
>>>>>>>>> 
>>>>>>>>> I think GitHub UI can not disable both the "Squash and
>>>>>>>>> merge" button
>>>>>>> and
>>>>>>>>> "Rebase and merge" at the same time if there exists any
>>>>>>>>> protected
>>>>>>> branch
>>>>>>>> in
>>>>>>>>> the repository(according to github rules).
>>>>>>>>> 
>>>>>>>>> If we only left "merge and commits" button, it will
>>>>>>>>> against requiring
>>>>> a
>>>>>>>>> linear commit history rules here
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>> https://help.github.com/en/github/administering-a-repository/requirin
>>> g-a-linear-commit-history
>>> <
>> https://help.github.com/en/github/administering-a-repository/requiring-a-linear-commit-history
>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>> 
>>> tison <wander4...@gmail.com> 于2020年3月5日周四 下午9:04写道:
>>>>>>>>> 
>>>>>>>>>> For implement it, file a JIRA ticket in INFRA [1]
>>>>>>>>>> 
>>>>>>>>>> Best, tison. [1]
>>>>>>>>>> https://issues.apache.org/jira/projects/INFRA
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Stephan Ewen <se...@apache.org> 于2020年3月5日周四 下午8:57写道:
>>>>>>>>>> 
>>>>>>>>>>> Big +1 to disable it.
>>>>>>>>>>> 
>>>>>>>>>>> I have never been a fan, it has always caused
>>>>>>>>>>> problems: - Merge commits - weird alias emails - lost
>>>>>>>>>>> author information - commit message misses the "This
>>>>>>>>>>> closes #<pr>" line to track
>>>>>>> back
>>>>>>>>>>> commits to PRs/reviews.
>>>>>>>>>>> 
>>>>>>>>>>> The button goes against best practice, it should go
>>>>>>>>>>> away.
>>>>>>>>>>> 
>>>>>>>>>>> Best, Stephan
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> On Thu, Mar 5, 2020 at 1:51 PM Yadong Xie
>>>>>>>>>>> <vthink...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> Hi Jark There is a conversation about this here:
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>> https://github.community/t5/How-to-use-Git-and-GitHub/Authorship-of-m
>>> erge-commits-made-by-Github-Apps-changed/td-p/48797
>>> <
>> https://github.community/t5/How-to-use-Git-and-GitHub/Authorship-of-merge-commits-made-by-Github-Apps-changed/td-p/48797
>>> 
>>>>>>>>>>>> 
>>>>> 
>>> I think GitHub will fix it soon, it is a bug, not a feature :).
>>>>>>>>>>>> 
>>>>>>>>>>>> Jingsong Li <jingsongl...@gmail.com> 于2020年3月5日周四 下
>>>>>>>>>>>> 午8:32写道:
>>>>>>>>>>>> 
>>>>>>>>>>>>> Thanks for deep investigation.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> +1 to disable "Squash and merge" button now. But
>>>>>>>>>>>>> I think this is a very serious problem, It
>>>>>>>>>>>>> affects too many
>>>>>>>>>> GitHub
>>>>>>>>>>>>> workers. Github should deal with it quickly?
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Best, Jingsong Lee
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On Thu, Mar 5, 2020 at 7:21 PM Xingbo Huang <
>>>>>>> hxbks...@gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Hi Jark,
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Thanks for bringing up this discussion. Good
>>>>>>>>>>>>>> catch. Agree
>>>>>>> that
>>>>>>>> we
>>>>>>>>>> can
>>>>>>>>>>>>>> disable "Squash and merge"(also the other
>>>>>>>>>>>>>> buttons) for now.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> There is a guideline on how to do that in
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>> https://help.github.com/en/github/administering-a-repository/configur
>>> ing-commit-squashing-for-pull-requests
>>> <
>> https://help.github.com/en/github/administering-a-repository/configuring-commit-squashing-for-pull-requests
>>> 
>>>>>>>>>>>>>> 
>>>>> 
>>> .
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Best, Xingbo
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Jark Wu <imj...@gmail.com> 于2020年3月5日周四 下午6:42写
>>>>>>>>>>>>>> 道:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Hi everyone,
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> We just noticed that everytime a pull request
>>>>>>>>>>>>>>> gets merged
>>>>>>>> with
>>>>>>>>>> the
>>>>>>>>>>>>>> "Squash
>>>>>>>>>>>>>>> and merge" button, GitHub drops the original
>>>>>>>>>>>>>>> authorship information and
>>>>>>> changes
>>>>>>>>>>>> "authored"
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>> whoever merged the PR.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> We found this happened in #11102 [1] and
>>>>>>>>>>>>>>> #11302 [2]. It
>>>>>>> seems
>>>>>>>>>> that
>>>>>>>>>>> it
>>>>>>>>>>>>> is
>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>> long outstanding issue and GitHub is aware of
>>>>>>>>>>>>>>> it but doesn't make an attempt to
>>>>>>> fix
>>>>>>>> it
>>>>>>>>>>>> [3][4].
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Before this behavior, "authored" is the
>>>>>>>>>>>>>>> original author and
>>>>>>>>>>>>> "committed"
>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>> the one who merged the PR, which was pretty
>>>>>>>>>>>>>>> good to record the contributor's
>>>>>>>> contribution
>>>>>>>>>> and
>>>>>>>>>>>> the
>>>>>>>>>>>>>>> committed information.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> From the perspective of contributors, it’s
>>>>>>>>>>>>>>> really
>>>>>>> frustrated
>>>>>>>> if
>>>>>>>>>>> their
>>>>>>>>>>>>>>> authorship information gets lost. Considering
>>>>>>>>>>>>>>> we don't know when GitHub will fix it, I
>>>>>>> propose
>>>>>>>> to
>>>>>>>>>>>> disable
>>>>>>>>>>>>>>> "Squash and merge" button (and also "Rebase
>>>>>>>>>>>>>>> and merge" button) before it is fixed.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> However, I'm not sure how to disable it. Can
>>>>>>>>>>>>>>> it be disabled
>>>>>>>> by
>>>>>>>>>>> GitHub
>>>>>>>>>>>>> UI
>>>>>>>>>>>>>> if
>>>>>>>>>>>>>>> who has administrator permission? Or
>>>>>>>>>>>>>>> .asf.yaml [5] is the right way?
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> What do you think?
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Best, Jark
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> [1]:
>>>>>>>>>>>>>>> https://github.com/apache/flink/pull/11102
>>>>>>>>>>>>>>> [2]:
>>>>>>>>>>>>>>> https://github.com/apache/flink/pull/11302
>>>>>>>>>>>>>>> [3]:
>>>>>>>>>>>>> 
>>>>>>>> https://github.com/chdsbd/kodiak/issues/300#issuecomment-595016815
>>>>>>>>>>>>>>> 
>>>>>>>> 
>>> [4]: https://github.com/isaacs/github/issues/1750
>>>>>>>>>>>>>>> [5]:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>> https://cwiki.apache.org/confluence/display/INFRA/.asf.yaml+features+
>>> for+git+repositories#id-.asf.yamlfeaturesforgitrepositories-Mergebuttons
>>> <
>> https://cwiki.apache.org/confluence/display/INFRA/.asf.yaml+features+for+git+repositories#id-.asf.yamlfeaturesforgitrepositories-Mergebuttons
>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>> 
>>> - --
>>>>>>>>>>>>> Best, Jingsong Lee
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>> -----BEGIN PGP SIGNATURE-----
>>> 
>>> iQIzBAEBCgAdFiEEI8mthP+5zxXZZdDSO4miYXKq/OgFAl5hZPoACgkQO4miYXKq
>>> /OiJ6RAAq9fUor5bdVpS8ETh7T3X+dPHM8bximQAOWI+EXL6BEyZDJ3LeDD9E71e
>>> QL3QsJLCfjUn4E/MDipyf2IBzGnkvNbWQiy+WpbjX1qrFc868WmoOI3sTnxApuvb
>>> gqsdd3SqJwpAX4jw3Y8wHmR4TehEOpt/ilUQ61hD0PakEuyWQfn1Y7T8J4/fibY7
>>> iYyuC61EhW/q/UwnP1/hRJlE2oQt4d15Xiapeb+eCDOlStR81G7VKNBIEYEVmadU
>>> uajNYHLabCLM8G686peOqNhiJAj5LxYQUMlWgpgGdQHe3wvb2amDzAGiP4Vb+92a
>>> mV7AxEQHGqN7DIXA6JwIBogHpId+3ZVzIwGq4C5/Aw6yhVe3eYKJ0AtAVFt4trVd
>>> iGtsk7RalNyvj5QZr/mE9TgrH06N5G3zFdGkrT8VIK1H7WZzny9JNguXnwgsH5vl
>>> gibxPt3Tt/ul8U28u+EHyclUc3BZQbilhgi3ARs8g+sAgUa++VRYwMHY2eW1tGH8
>>> Yq163CP7+6SblTOSnuyrVkKhXaLUXjqDH5f/uXiJ19U4Z5PoznDv3Y7dp8rOCGIW
>>> 5Z/s/afH/6PLaoxnDiPqnNfDLZx+aMLYX6IB89+JFMLCREkao2Fbha2P+8B61WT4
>>> ugK6iSAQnfDo2faP1HsFneT7unNQeEr3t7uu6ETwlpN0+eq3XH8=
>>> =oznE
>>> -----END PGP SIGNATURE-----
>>> 
>> 
>> 
>> --
>> Best, Jingsong Lee
>> 

Reply via email to