[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Python-Dev] GH-NNNN vs #NNNN in merge commit

On 1/25/2018 4:34 PM, Berker Peksa? wrote:
> On Fri, Jan 26, 2018 at 12:09 AM, Terry Reedy <tjreedy at udel.edu> wrote:
>> On 1/25/2018 1:53 PM, Brett Cannon wrote:
>>> I would assume it would just go into miss-islington, but before we get
>>> ahead of ourselves and design this we need to get consensus that people like
>>> the overall idea of using a bot to do a main commits as well.
>> I strongly dislike any idea of making me do more error-prone work when
>> merging.
> The whole point of writing a bot is to automatize the steps listed at
> https://devguide.python.org/gitbootcamp/#accepting-and-merging-a-pull-request

The point is to automate

"2. Replace the reference to GitHub pull request #NNNN with GH-NNNN."

which in itself is trivial (and would be welcome).  (I am not sure that 
I ever read this ;-). But is would be harder to automate the next sentence.

"If the title is too long, the pull request number can be added to the 
message body."

and impossible to properly automate

"3. Adjust and clean up the commit message."

Looking at the example, a bot cannot turn this 'bad' message

* Improve the spam module
* merge from master
* adjust code based on review comment
* rebased

into this 'good' message.

* Add method A to the spam module
* Update the documentation of the spam module

Actually, I think this would be even better with the '* 's deleted and 
the missing '.'s added.  But good message style is another issue.

> and https://devguide.python.org/gitbootcamp/#backporting-merged-changes

Miss Islington already handles these bad-good differences.

> so you won't have to do bunch of manual edits before pressing the
> "Confirm squash and merge" button.

Human intelligence is required to write a good commit message, which I 
try to do.  I am aware that some people just commit the concatenated 
commit messages, as in the bad example above, but I think the best a bot 
could do is to refuse to merge.

An alternate approach would be to ask people to edit the initial commit 
message into the final version before merging, but I don't think this 
would be a good idea.

Terry Jan Reedy