Always put the unabbreviated commit IDs in the generated commit messages
and other places. This prevents the developer's `core.abbrev` git setting
from leaking through and is better against ambiguity too.
The API request limit for unauthenticated requests is quite low.
I started running into rate limiting errors. The limit
for authenticated requests is much higher.
This patch adds an optional configuration setting `user.ghtoken`
that, when set, is used to authenticate requests to the API.
Fetch the destination branch as well as PR in one go. Saves a few
seconds (as well as one ssh authentication, when using a yubikey) when
using github-merge.py.
Some minor github-merge improvements I've made over time:
User interface:
- Print merge details again before signing off, to refresh your memory -
usually I'll have done lots of different things in the shell so this
will have scrolled out a long time ago.
- Require a valid answer on the prompts. One of the requested answers
must be typed, if not, the prompt will re-ask. This prevents
accidentally rejecting.
Efficiency:
- Condense "accept merge" and "sign off" prompts. There's no reason to
have this as two separate prompts, both are just opportunities to skip
out on the merge, no action is performed in between.
Merging:
- Strip spaces from github title. This avoids redundant spaces
surrounding it from getting into the commit message.
This changes tree_sha512sum() to requests the objects for hashing from
git instead of from the working tree.
The change should make the process more deterministic (it hashes what
will be pushed) and hopefully avoids the frequent miscomputed SHA512's
that happen now.
bbd7579 Fix regsig checking for subkey sigs in verify-commits (Matt Corallo)
d025bc7 Allow any subkey in verify-commits (Matt Corallo)
eddc77a Add comment re: why SHA1 is disabled (Peter Todd)
d9c450f Verify Tree-SHA512s in merge commits, enforce sigs are not SHA1 (Matt Corallo)
be908a6 Fail merge if there are any symlinks (Matt Corallo)
Tree-SHA512: bb66c59cc1c6b1c86d7d8be7adb0769c6598c0e28ad927409941f30af87d390521e82fc13700ee22e92db1bd571db3e19a152ec7b2c0349c6e06f5de62c0b65f
Three categories of modifications:
1)
1 instance of 'The Bitcoin Core developers \n',
1 instance of 'the Bitcoin Core developers\n',
3 instances of 'Bitcoin Core Developers\n', and
12 instances of 'The Bitcoin developers\n'
are made uniform with the 443 instances of 'The Bitcoin Core developers\n'
2)
3 instances of 'BitPay, Inc\.\n' are made uniform with the other 6
instances of 'BitPay Inc\.\n'
3)
4 instances where there was no '(c)' between the 'Copyright' and the year
where it deviates from the style of the local directory.
As we are already using the API to retrieve the pull request
title, also retrieve the base branch.
This makes sure that pull requests for 0.12 automatically end up in
0.12, and pull requests for master automatically end up in master,
and so on.
It is still possible to override the branch from the command line
or using the `githubmerge.branch` git option.
This makes github-merge.py the first developer tool to go
all Python 3 (for context see #7717).
The changes are straightforward as the script already was
`from __future__ import division,print_function,unicode_literals`.
However urllib2 changed name, and json will only accept unicode data not
bytes.
This retains py2 compatibility for now: not strictly necessary
as it's not used by the build system - but it was easy.
Use 'utf-8' instead of the Python 2 default of 'ascii' to encode/decode
commit messages.
This can be removed when switching to Python 3, as 'utf-8' is the
default there.
Necessary for merging #7422 due to the ฿ in ฿tcDrak.
This is meant to be a direct translation of the bash script,
with the difference that it retrieves the PR title from github,
thus creating pull messages like:
Merge #12345: Expose transaction temperature over RPC
