Hi,
In other Apache projects using gitbox, I experiment, the following cinematic:
1. use the review button to assign someone
2. once changes approved, I use the merge button (supporting squash and merge)
It's very convenient and works fine.
So, +1 to (b)
Regards
JB
On 11/28/2017 06:45 PM, Kenneth Knowles wrote:
Hi all,
James brought up a great question in Slack, which was how should we use the
merge button, illustrated [1]
I want to broaden the discussion to talk about all the new capabilities:
1. Whether & how to use the "reviewer" field
2. Whether & how to use the "assignee" field
3. Whether & how to use the merge button
My preferences are:
1. Use the reviewer field instead of "R:" comments.
2. Use the assignee field to keep track of who the review is blocked on (either
the reviewer for more comments or the author for fixes)
3. Use merge commits, but editing the commit subject line
To expand on part 3, GitHub's merge button has three options [1]. They are not
described accurately in the UI, as they all say "merge" when only one of them
performs a merge. They do the following:
(a) Merge the branch with a merge commit
(b) Squash all the commits, rebase and push
(c) Rebase and push without squash
Unlike our current guide, all of these result in a "merged" status for the PR,
so we can correctly distinguish those PRs that were actually merged.
My votes on these options are:
(a) +1 this preserves the most information
(b) -1 this erases the most information
(c) -0 this is just sort of a middle ground; it breaks commit hashes, does not
have a clear merge commit, but preserves other info
Kenn
[1] https://apachebeam.slack.com/messages/C1AAFJYMP/
Kenn
--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
