| Age | Commit message (Collapse) | Author |
|---|
|
They are much more useful if b4.thanks-commit-url-mask is set, but even
without them this will list all subjects and corresponding commit IDs.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
New experimental feature that aims to simplify a very common "thanks,
applied" kind of feedback often expected of maintainers. Still needs
documentation to explain its usage.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
When a pull request is generated using git-request-pull, the base commit
is specified in the body of the message. However, in other cases this
information can be missing, so we can use git merge-base to find out
what it is after we've performed a "git fetch".
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
We need a valid mboxo format for python, so make sure to escape all
From lines not actually starting a new message, per mboxo requirements.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
Since we aren't planning on sending any of this as actual emails,
convert EVERYTHING into utf-8 before writing messages, including
QP-escaped 7-bit headers.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
We now use similar subroutines for checking signatures on FETCH_HEAD as
we do for patch attestation, making it a convenient operation during the
fetch stage:
$ b4 pr 202003292114.2252CAEF7@keescook
Looking up https://lore.kernel.org/r/202003292114.2252CAEF7@keescook
Grabbing thread from lore.kernel.org
Looking at: [GIT PULL] seccomp updates for v5.7-rc1
Fetching https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/seccomp-v5.7-rc1
---
[✓] Attestation-by: Kees Cook <keescook@chromium.org> (pgp: 8972F4DFDC6DC026)
---
Successfully fetched into FETCH_HEAD
Hopefully, I didn't introduce too many bugs into patch attestation,
since I had to rewrite the backend a bit to work for both native git
operations and patch attestation calls.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
Fix some leftover bugs from prototyping stage when we were always
assuming to run from a checkout.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
No need to add an extra From: into the body of the message if it's
identical to the From in the original pull request.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
Fix a few most glaring problems performing explode on a message that was
not formatted using git-request-pull.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
While working on "pull-request exploder" stuff for achiving on
lore.kernel.org, I realized that this may be a useful set of features
for developers as well, so here is a very simple framework for handing
pull requests. Examples:
b4 pr <msgid>
- downloads that message
- parses the pull request
- checks that the remote tip is where the message says it should be
- makes sure the base-commit is present in the tree
- makes sure the tip commit isn't already in one of the branches
- checks if FETCH_HEAD already is at that commit
- if the above two checks pass, performs a git fetch
b4 pr --check <msgid>
Runs all of the checks above, but doesn't perform the actual fetch.
Useful if you don't remember if you've already processed a pull
request or not.
b4 pr --explode <msgid>
Runs basic sanity checks and then:
- performs a git fetch
- runs a "git format-patch" for base-commit..FETCH_HEAD
- adds the same to/from/cc headers as in the pull request
- properly threads each patch below the pull request
- saves that into a <msgid>.mbox file
The above is handy if you want to comment on something in a pull
request and not have to hunt around for sender/cc information.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|