Hey Sean, I just gave a try to Github CLI and merged a PR, using the command:
*gh pr merge 3600 --squash --body "HDFS-16290.--Message--"* Unfortunately this also has the same result, nothing different. -Ayush On Tue, 26 Oct 2021 at 21:25, Sean Busbey <sbus...@apple.com> wrote: > If you add a line in the commit message that the commit closes a given PR > # then GitHub will annotate the PR as related to the specific commit and > close it for you. > > i.e. you can add “closes #3454” to the commit message body and then PR > 3454 will close and link to that commit when it hits the default branch. > > I believe these docs describing associating a GitHub issue via a commit > message also apply to associating commits to pull requests, if you are > interested in what specific phrases work: > > > https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword > > > Has anyone tried handling a squash merge via the GitHub CLI tooling rather > than the web or plain git tooling? Does it similarly overwrite committer > metadata? > > e.g. the GitHub CLI example from the merging PRs docs? > > > https://docs.github.com/en/github/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/merging-a-pull-request#merging-a-pull-request > > > > On Oct 25, 2021, at 9:57 AM, Szilárd Németh <snem...@apache.org> wrote: > > Hi Ayush, > Thanks a lot for your response. > > > Yahh, remember chasing Github support regarding this last year and they > reverted back that they are aware of this and have an internal jira for > this but can not comment upon how much time it would take. (As of now 1 > year & counting) > > So if I get this right: Their internal jira is in the same untouched state > and they wouldn't make any progress? > > > Just in case you want to use the CLI & still make the PR marked as merged, > > A dirty way to do this is: > Pull the changes to your local. > Rebase & Squash all commits, in the commit message in the end put actual > the PR number, eg. #1234, > force push to the PR, that is the contributors fork, this will update his > PR and then merge the Branch to trunk in your local and push. It marks > the PR as merged, at least last year it did when I tried. :-) > > > Thanks for this dirty hack :) > Probably I will refrain from doing this, I don't like to force push if it's > not "mandatory". > Anyway, if the community is fine with it, I will continue to commit from > the CLI and close the PR, even though it's not that convenient. > > > Best, > Szilard > > > > On Wed, 20 Oct 2021 at 05:07, Ayush Saxena <ayush...@gmail.com> wrote: > > Yahh, remember chasing Github support regarding this last year and they > reverted back that they are aware of this and have an internal jira for > this but can not comment upon how much time it would take. (As of now 1 > year & counting) > > As far as I remember this is with squash & commit only. If you do say a > rebase & merge. The commit email id is preserved. But other options we have > blocked. > > I think most of the projects are using squash & merge and many people > won’t be ok to use CLI rather than UI > So, I don’t think we have an ALT here. > > Just in case you want to use the CLI & still make the PR marked as merged, > A dirty way to do this is: > Pull the changes to your local. > Rebase & Squash all commits, in the commit message in the end put actual > the PR number, eg. #1234, > force push to the PR, that is the contributors fork, this will update his > PR and then merge the Branch to trunk in your local and push. It marks the > PR as merged, at least last year it did when I tried. :-) > > -Ayush > > > On 20-Oct-2021, at 3:27 AM, Szilárd Németh <snem...@apache.org> wrote: > > Hi, > > I noticed something strange in our commits, in particular the committer > field is not reflecting the user who committed the commit. > > *1. First, I wanted to check Gergely's commits from the last month or so. > This was getting to be suspicious as I expected to see a bunch of commits > from Sept / Oct of this year. * > > *git log CLI output:* > ➜ git --no-pager log --format=fuller --committer=shuzirra > commit 44bab51be44e31224dabbfa548eb27ea5fb2f916 > Author: Gergely Pollak <shuzi...@apache.org> > AuthorDate: Wed Aug 4 15:43:07 2021 +0200 > Commit: Gergely Pollak <shuzi...@apache.org> > CommitDate: Wed Aug 4 15:43:57 2021 +0200 > > > YARN-10849 Clarify testcase documentation for > TestServiceAM#testContainersReleasedWhenPreLaunchFails. Contributed by > Szilard Nemeth > > > commit e9339aa3761295fe65bb786e01938c7c177cd6e7 > Author: Gergely Pollak <shuzi...@cloudera.com> > AuthorDate: Tue Jun 1 15:57:22 2021 +0200 > Commit: Gergely Pollak <shuzi...@cloudera.com> > CommitDate: Tue Jun 1 15:57:22 2021 +0200 > > > YARN-10797. Logging parameter issues in scheduler package. Contributed > by Szilard Nemeth > > > *2. Another example of a merged PR, here I was the author and Adam Antal > was the committer: * > PR link: https://github.com/apache/hadoop/pull/3454 > > *git log CLI output:* > ➜ git --no-pager log --format=fuller a9b2469a534 -1 > commit a9b2469a534c5bc554c09aaf2d460a5a00922aca > Author: Adam Antal <aada...@gmail.com> > AuthorDate: Sun Sep 19 14:42:02 2021 +0200 > Commit: GitHub <nore...@github.com> > CommitDate: Sun Sep 19 14:42:02 2021 +0200 > > > YARN-10950. Code cleanup in QueueCapacities (#3454) > > > *3. Let's see another two example of merged PRs by Gergely and how the > > git > > log CLI output look like for these commits: * > > *3.1.* > PR link: https://github.com/apache/hadoop/pull/3419 > Commit: > > > https://github.com/apache/hadoop/commit/4df4389325254465b52557d6fa99bcd470d64409 > > > *git log CLI output:* > ➜ git --no-pager log --format=fuller > 4df4389325254465b52557d6fa99bcd470d64409 -1 > commit 4df4389325254465b52557d6fa99bcd470d64409 > Author: Szilard Nemeth < > > 954799+szilard-nem...@users.noreply.github.com> > > AuthorDate: Mon Sep 20 16:47:46 2021 +0200 > Commit: GitHub <nore...@github.com> > CommitDate: Mon Sep 20 16:47:46 2021 +0200 > > > YARN-10911. AbstractCSQueue: Create a separate class for usernames and > weights that are travelling in a Map. Contributed by Szilard Nemeth > > > *3.2. * > PR link: https://github.com/apache/hadoop/pull/3342 > Commit: > > > https://github.com/apache/hadoop/commit/9f6430c9ed2bca5696e77bfe9eda5d4f10b0d280 > > > *git log CLI output:* > ➜ git --no-pager log --format=fuller > 9f6430c9ed2bca5696e77bfe9eda5d4f10b0d280 -1 > commit 9f6430c9ed2bca5696e77bfe9eda5d4f10b0d280 > Author: 9uapaw <gyora...@gmail.com> > AuthorDate: Tue Sep 21 16:08:24 2021 +0200 > Commit: GitHub <nore...@github.com> > CommitDate: Tue Sep 21 16:08:24 2021 +0200 > > > YARN-10897. Introduce QueuePath class. Contributed by Andras Gyori > > > As you can see, the committer field contains: *"GitHub < > > nore...@github.com > > <nore...@github.com>>".* > Is this something specific to Hadoop or our Gitbox commit environment? > Basically, any PR merged on the github.com UI will lose the committer > information in the commit, which is very bad. > > As I think reviewing and having discussion on Github's UI is way better > than in jira, the only thing that makes sense for me to do perform as a > workaround is that downloading the patch from Github before the commit, > then commit from the CLI by adding the author info, optionally appending > the standard "Contributed by <name>" message to the commit message. > For example: > > git commit -m "YARN-xxx. <Commit message> Contributed by <author's full > name>" --author=<author's username> > > This way, both the author and committer field will be correct. One > > downside > > is that the PR won't be merged on Github, it will be in closed state > because the commit is committed from the CLI, so the Github PR will have > > a > > misleading status. > > What do you think? > What is your workflow for commits? > > > Thanks, > Szilard > > > > >
