Hi, > I assume that the GH API approach would be able to preserve the > author/co-author attribution
Yes. https://github.com/apache/arrow/pull/13184 does it. https://github.com/apache/arrow/commit/6faee474db2ff246f798d63b79a3100a1f15204c was merged by https://github.com/apache/arrow/pull/13184 . The commit includes Authored-by: and Signed-off-by:. Other trailers are also included if needed. Because https://github.com/apache/arrow/pull/13184 still uses the same logic as the current "git merge" approach. Thanks, -- kou In <cajpuwmdzaab+fs_bepdjnbakjiy52ctfk88ugvs4vohqmdn...@mail.gmail.com> "Re: Merge a pull request with GitHub API" on Wed, 18 May 2022 10:12:11 -0700, Wes McKinney <wesmck...@gmail.com> wrote: > One of the benefits of the current merge script is that the PR > description is preserved (maybe this could be possible with this > method) — authors and co-authors are preserved by the explicit > by-lines, e.g. > > Lead-authored-by: Nic Crane <email omitted> > Co-authored-by: Ian Cook <email omitted> > Signed-off-by: Ian Cook <email omitted> > > I assume that the GH API approach would be able to preserve the > author/co-author attribution > > On Wed, May 18, 2022 at 5:55 AM Raul Cumplido Dominguez > <r...@voltrondata.com> wrote: >> >> I like the idea. As a new contributor is something that also confused me. >> It also has the side effect of easily identifying PRs that have been merged >> vs PRs that have been closed without merging which require some more >> investigation with the current workflow. >> >> On Wed, May 18, 2022 at 10:16 AM Jarek Potiuk <ja...@potiuk.com> wrote: >> >> > Just a small comment here - (friendly comment from a visitor :). If >> > you are following squash & rebase workflow - in Apache Airflow we >> > exclusively merge with GitHub UI's merge. >> > >> > You can configure .asf.yml to only allow "squash & rebase" and then >> > squashing and rebasing happens automatically when you merge from the >> > UI. It also gives a chance to revise and update the commit message of >> > such squash & rebase while doing it. >> > >> > https://pasteboard.co/qV1LfChsxAIn.png >> > >> > I know it's not a command line one, but It has really nice properties :). >> > >> > J. >> > >> > On Wed, May 18, 2022 at 10:07 AM Antoine Pitrou <anto...@python.org> >> > wrote: >> > > >> > > >> > > That sounds ok to me, we should just ensure that commits are squashed >> > > and rebased on top of the main/master branch. >> > > >> > > (also, the commit title and description should inherit the PR's >> > > corresponding fields) >> > > >> > > >> > > Le 18/05/2022 à 05:43, Sutou Kouhei a écrit : >> > > > Hi, >> > > > >> > > > How about using GitHub API instead of local "git merge" to >> > > > merge a pull request? >> > > > >> > > > >> > > > We use local "git merge" to merge a pull request in >> > > > dev/merge_arrow_pr.py. >> > > > >> > > > If we use "git merge" to merge a pull request, GitHub's Web >> > > > UI shows "Closed" mark not "Merged" mark in a pull request >> > > > page. This sometimes confuses new contributors. "Why was my >> > > > pull request closed without merging?" See >> > > > https://github.com/apache/arrow/pull/12004#issuecomment-1031619771 >> > > > for example. >> > > > >> > > > If we use GitHub API >> > > > https://docs.github.com/en/rest/pulls/pulls#merge-a-pull-request >> > > > to merge a pull request, GitHub's Web UI shows "Merged" mark >> > > > not "Closed" mark. See >> > > > https://github.com/apache/arrow/pull/13180 for example. I >> > > > used GitHub API to merge the pull request. >> > > > >> > > > And we don't need to create a local branch on local >> > > > repository to merge a pull request. But we must specify >> > > > ARROW_GITHUB_API_TOKEN to run dev/merge_arrow_pr.py. >> > > > >> > > > >> > > > See also: >> > > > >> > > > * https://issues.apache.org/jira/browse/ARROW-16602 >> > > > * https://github.com/apache/arrow/pull/13184 >> > > > >> > > > >> > > > Thanks, >> >
