Age | Commit message (Collapse) | Author |
|
Still a bit slim on documentation, but this is better than nothing. I
need to write a better README file that will introduce maintainers to
most useful functionality aspects of b4.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
If we find a ~/.signature, then use it for making a default ${signature}
value, otherwise make a "Name <email>" boring one.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
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>
|
|
Looks like some of the patches sent from quilt (at least from Andrew
Morton) are not properly parsed by git patch-id, so use our own patch
hashing routines, even if this means we're likely going to miss some of
the patches that were edited by maintainers.
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>
|
|
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
If we have multiple versions of patch series in the same thread and
someone adds a follow-up trailer to a patch in v1, but doesn't do it for
the same *exact* patch in v2, then we carry over that trailer from v1 to
v2.
We use attestation hashes for this purpose, so all patch/metadata must
be exact in order for the trailer to be reused.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
Message-IDs that are using escaped characters are breaking our lookup
due to the refactoring that was necessary for backfilling. This should
help deal with such cases.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
When we query by message-id, sometimes the list that is returned is not
the best one to use, because it is lossy. Look at other addresses in the
to/cc fields, and if we find another list address that is also backed up
on lore.kernel.org, then attempt to backfill missing messages from those
lists, until the entire series is complete.
This should become obsolete in the future once public-inbox gains
ability to return a thread sourced from multiple lists/feeds, but this
should be a useful stop-gap measure to help developers in the meantime.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
Sometimes this happens:
[PATCH v2 1/N]
[PATCH 2/N]
[PATCH 3/N]
[PATCH 4/N]
Properly recognize such cases and version all patches threaded under the
first one as v2.
Reported-by: Amit Kucheria <amit.kucheria@gmail.com>
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>
|
|
For ease of tracking version information for folks running things
straight out of the checkout, add current git revision to the version
info string.
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>
|
|
Switching to using sets for all trailer management resulted in trailer
order being non-deterministic for trailers with the same title. Switch
back to using lists where it makes a difference.
Reported-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
When we use a specific project either via -p or via parsing the full
lore URL, don't use the generic lookup cache location.
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>
|
|
When a message contains no text/plain contents, then it's not anything
we can use and we should toss them out early.
Reported-by: Jason Donenfeld <Jason@zx2c4.com>
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
Provide a warning when we are ignoring trailers due to from/name
mismatch between the headers and the body. Also provides a
-S,--sloppy-trailers option to ignore all mismatches.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
When piped from other tools, the msgid may be prepended by extraneous
info, so strip it to grab the actual msgid.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
Change b4.sh to handle being symlinked to in order to find out where it
"lives".
This allows me to have a symlink in my local ~/bin/ called b4 that links
to the git repo's b4.sh and have everything work properly.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
There's never a situation where we can have legitimate duplicate entries
for trailers, so switch to using sets.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
When the same person sends multiple sets of patches on the same day, we
risk colliding between them. Use mbx names with cover/1st-patch subjects
in them, to help disambiguate in such cases.
Reported-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
Fun read:
https://packaging.python.org/guides/single-sourcing-package-version/
Anyway, I hated this way the least.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
Prevent ourselves from being installable on python versions earlier than
what we support.
Reported-by: James Bottomley <James.Bottomley@hansenpartnership.com>
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
Checking for newer versions always requires going out to
lore.kernel.org, so force nocache operation.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
Many lore.kernel.org operations can be repeated within quick succession
of each-other (e.g. someone reruns a query with -t). This commit adds a
caching layer that keeps lookups in local cache for 10 minutes
(default). It can be made longer or shorter by editing the
'cache-expire' setting, or running "b4 am" with -C,--no-cache.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
The horrible things people do to their patch subjects continue to amaze
me.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
Make the name a bit more convenient to invoke and document that it can
be set as an alias.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
Add the b4-wrapper.sh script that allows running
b4 from a git working directory.
Signed-off-by: Geoff Levand <geoff@infradead.org>
|
|
We don't need to strip() patches, because a) it introduces a problem if
the patch has blank lines in it, and b) because it doesn't matter if
there's anything trailing at the end.
We still need better handling for obviously broken patches, but at least
valid ones shouldn't cause problems.
Reported-by: Geoff Levand <geoff@infradead.org>
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
Anyone who wants a convenient wrapper to run things from the git
checkout without installing pip packages can set up a two-liner wrapper
script and put it in their path.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
No longer need to change version in both places.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
There are special cases where we have:
cover: [PATCH v3 00/NN] Foo
\- [PATCH 01/NN] Patch 1
- [PATCH 02/NN] Patch 2
While the submitter *should* be setting "v3" in all patches, it's not
uncommon to have that inferred from the cover letter. When cover letter
is properly upthread from the patch that has an inferred v1 revision, we
can check the revision on the cover letter and fix the patch revision to
match.
Reported-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
I should have it simply use the version in b4/__init__.py
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
If attestation is over 30 days older than the patch, then we refuse to
accept it. This can be changed in configuration parameters by setting
'attestation-staleness-days' to a higher/lower value.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
If one patch in the series fails attestation, show which one it is and
point out which part failed (commit metadata, commit message, or patch
content). At this time, this only works if it's not the *first* patch
that fails attestation, because otherwise we aren't able to locate the
attestation document in the first place. There's no simple solution
here, because otherwise we'd have to hit lore too many times, which
would be murder on large series.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
Querying signatures without the trailing slash results in an extra 301
hop that is unnecessary.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
Don't backtrace if there are no commands passed on cmdline.
Reported-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|