aboutsummaryrefslogtreecommitdiff
path: root/b4/command.py
AgeCommit message (Collapse)Author
2022-09-01ez: add b4 -F to allow (re-)creating branches from threadsKonstantin Ryabitsev
It is now possible to create a b4-tracked branch from an arbitrary thread (or from a previously sent b4-tracked series): b4 prep -F [msgid-of-the-series] Example: $ b4 prep -F 20220901194310.115427-1-tony.luck@intel.com Grabbing thread from lore.kernel.org/all/20220901194310.115427-1-tony.luck%40intel.com/t.mbox.gz Checking attestation on all messages, may take a moment... --- ✓ [PATCH 1/3] EDAC/skx_common: Use driver decoder first ✓ [PATCH 2/3] EDAC/skx_common: Make output format similar ✓ [PATCH 3/3] EDAC/i10nm: Add driver decoder for Ice Lake and Tremont CPUs --- ✓ Signed: DKIM/intel.com --- Created new branch b4/edac_improve_memory Applying 3 patches --- Applying: EDAC/skx_common: Use driver decoder first Applying: EDAC/skx_common: Make output format similar Applying: EDAC/i10nm: Add driver decoder for Ice Lake and Tremont CPUs --- NOTE: any follow-up trailers were ignored; apply them with b4 trailers -u This makes it easier to start tracking pre-existing series with b4 prep. Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
2022-08-31Refactor how we handle trailersKonstantin Ryabitsev
With the addition of b4 trailers it became pretty obvious that the way we originally implemented trailers didn't age well. This refactor does the following: - introduces LoreTrailer class to replace passing trailers as tuples - reimplements trailer-order with strict adherence to chain-of-custody rules - adds tests to most common trailer follow-up/ordering cases Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
2022-08-30ez: reimplement --resendKonstantin Ryabitsev
Instead of --resend just being a flag to add a RESEND prefix, allow us to actually resend a previously sent series using the tag we have applied and stored in sent/. E.g. if we have previously sent a v2, thus automatically rerolling a v3, we can resend a v2 again without needing to do anything else by using: b4 send --resend v2 alternatively, we can use a full tag name: b4 send --resend sent/some-series-topic-v2 Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
2022-08-23ez: move the RESEND prefix into --resend switchKonstantin Ryabitsev
For UX reasons, make --resend a separate switch instead of operating on the --prefixes RESEND logic. Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
2022-08-22ez: allow passing --since to b4 trailersKonstantin Ryabitsev
Reduce the default range to 1.month and allow overriding with other values when trying to update trailers from arbitrary ML threads. Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
2022-08-17ez: initial rework of web submission endpointKonstantin Ryabitsev
Reimplement initial enrolment with the web submission endpoint. A lot more work is required before this is useful, but we're at least able to authenticate received messages. Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
2022-08-16ez: support enrolling branches using tagsKonstantin Ryabitsev
Allow using tags when enrolling branches instead of only allowing branch names. In fact, with the default "commit" strategy we can even enroll using something like HEAD~3, but that's not recommended for newbies -- just pass the branch name. Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
2022-07-26ez: another overhaul of commands and flagsKonstantin Ryabitsev
Another, hopefully final overhaul of commands and flags: - "b4 ez-series" is now "b4 prep" - "b4 ez-trailers" is now "b4 trailers" - "b4 ez-send" is now "b4 send" I've also split on-disk output into two different commands: b4 prep --format-patch <outdir>: does not set To/Cc and doesn't do any From magic. In effect, it's as close as it gets to git format-patch output compatibility. b4 send --dry-run -o <outdir>: generates the messages exactly as they are about to be sent, then writes them out to the directory specified. Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
2022-07-20ez-series: add --show-revision and --force-revisionKonstantin Ryabitsev
Show current revision with --show-revision and allow setting it to an arbitrary integer using --force-revision. Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
2022-07-20ez: refactor based on initial feedbackKonstantin Ryabitsev
Significant refactor of (formerly) "b4 submit" based on initial feedback: 1. Split "b4 submit" into three different commands: - ez-series: for managing the series cover letters, tracking info, etc - ez-trailers: for retrieving trailers and updating commits (works on any branch, not just ez-series branches) - ez-send: for sending branches managed by ez-series 2. Refactor to support multiple cover letter strategies: - the default "commit" strategy that keeps the cover letter in an empty commit (should be backwards-compatible with "b4 submit") - the non-invasive "branch-description" strategy that keeps the cover letter in the branch.branchname.description configuration setting and tracking in branch.branchname.b4-tracking - the not-yet-implemented "tag" strategy that mimics the behaviour of git-publish The strategy can be set via b4.ez-cover-strategy variable, e.g. in your .gitconfig: [b4] ez-cover-strategy = branch-description Note, that converting from one strategy to another doesn't work and will probably explode in weird ways right now. Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
2022-07-15Initial implementation of b4 submitKonstantin Ryabitsev
This is the first rough implementation of "b4 submit". Currently implemented: - b4 submit --new : to start a new branch - b4 submit --edit-cover : to edit the cover message - b4 submit --update-trailers : to receive latest trailer updates from the mailing lists - b4 submit --send : sends the messages using existing git.sendemail configs For details, see "b4 submit --help". Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
2022-06-27Remove support for trailer-orderKonstantin Ryabitsev
Per discussion on the mailing lists, reordering trailers is almost never the right decision, so remove support for trailer ordering completely. Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
2022-06-27Remove "b4 attest" subcommandKonstantin Ryabitsev
We've deprecated "b4 attest" two versions ago, so remove it completely now. Everyone should use "patatt attest" instead. Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
2022-06-21Initial patchwork integration supportKonstantin Ryabitsev
A lot of maintainers use patchwork alongside b4, to make it easier to track patches and rely on some CI integration. This commit adds some basic patchwork integration: - on "b4 am", "b4 shazam", "b4 pr" we will mark the relevant patchwork entries as "Under Review" - on "b4 ty" we can set these patches as "Accepted" - on "b4 ty -d" we can set them as "Deferred" To make it work, the following entries must be present in the repository used with b4: [b4] pw-key = (your API token) pw-url = https://patchwork.kernel.org pw-project = (your project, e.g. linux-usb) pw-review-state = under-review pw-accept-state = accepted pw-discard-state = deferred To get your patchwork API token, go to your patchwork profile page. The pw-accept-state and pw-discard-state can be overridden using the --pw-set-state flag to "b4 ty". E.g. if you wanted to mark the patches as "Not applicable": b4 ty -d 5 --pw-set-state not-applicable Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
2022-06-17Add ability to exit before git-merge is invokedKonstantin Ryabitsev
It may be useful for the maintainer to review b4 retrieval/validation output before git-merge is invoked, so add a pause requiring an Enter or Ctrl-C. Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
2022-06-16Implement "b4 shazam -M" that execs git-mergeKonstantin Ryabitsev
In addition to just being able to fetch a series into FETCH_HEAD, also add an option to exec git-merge automatically so that people don't have to cut-and-paste the merge command to use with paths to the cover letter. Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
2022-06-16Allow breaking threads using --no-parentKonstantin Ryabitsev
It is a common request to be able to get a partial thread in case someone submitted an auxiliary standalone patch in the middle of a larger patch series. Passing the msgid of the start of the thread along with --no-parent should tell b4 to break the thread at the start of the message-id specified and only consider that message and its children. Suggested-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/tools/YpTI9lhCfA7shi6j@sirena.org.uk/ Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
2022-06-14am: Fix broken guessbranch handlingRob Herring
b4's usage of git-log '--branches' option is broken. The option takes a glob pattern *only* and must have an '=', but b4 ends up passing '--branches <guessbranch>' to git-log. This will kind of work, but is not checking only 'guessbranch'. For example, these 3 commands all do something different: git log -1 --branches=master git log -1 --branches master git log -1 --branches=*aster A maintainer wanting to apply a patch or series likely has a small set of known branches they apply patches to. Using a glob pattern is not a good fit for that. Instead, allow --guess-branch to be repeated and to take fixed refs. Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org> Link: https://lore.kernel.org/r/20220331195346.1384515-1-robh@kernel.org
2021-11-01mbox: initial support to check for unicode control charsKonstantin Ryabitsev
Implement initial support for checking if the patch message contains unicode control characters that can be used to trick code reviewer into accepting maliciously formatted code. Link: https://lore.kernel.org/tools/20211101175020.5r4cwmy4qppi7dis@meerkat.local/ Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
2021-10-20ty: fix bugs introduced when switching -s to -tKonstantin Ryabitsev
Test out and fix the bugs introduced by switching flags. Reported-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
2021-10-20shazam: change default behaviour to be "apply-here"Konstantin Ryabitsev
Based on the feedback, change the default behaviour of "b4 shazam" to apply patches to the current tree instead of doing FETCH_HEAD magic. This is still available when used with -H,--make-fetch-head flag. Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
2021-10-19Initial implementation of native mail sendingKonstantin Ryabitsev
I'm felling comfortable that "b4 ty" is sufficiently mature at this point to implement sending thank-yous directly. This is only the initial implementation that covers only the very basic parts of git's sendemail configuration options, but this should actually cover 90% of cases if not more. One important caveat -- I moved the "b4 ty -s" flag to be "b4 ty -t" in order to disambiguate it from the capital -S (that actually does the sending). Since "b4 ty" is still marked as an experimental feature, I feel we can do this without much impact. Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
2021-09-21Add "b4 shazam" that is like b4 am + git amKonstantin Ryabitsev
By popular demand, provide a way to apply series straight to a git repository. By default, we're still going the safest possible route: - create a sparse worktree consisting just of the files being modified - run "git am" against the temporary worktree - if "git am" went well, fetch from the temporary worktree into our current tree and leave everything in FETCH_HEAD - unless we're running "b4 shazam -A" in which case we just apply to the current HEAD (exact equivalent of b4 am -o- | git am) Further changes to come based on feedback. Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
2021-06-22Additional --guess-base refinementsKonstantin Ryabitsev
Use --all by default, instead of limiting ourselves just to the current HEAD. This is actually a faster operation, because we don't have to pre-filter results. Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
2021-06-21Reimplement --guess-baseKonstantin Ryabitsev
Based on some feedback, attempt to reimplement --guess-base by looking at the file index hashes and using --find-object to locate when they were last changed. We limit this using --since and --until, so that we aren't trying to look through the entire history of the repo. For the --until date, we take the date of the patch. For the --since date, we take the timedelta using the number of days specified by --guess-lookback (default is 14 days). Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
2021-06-08Tentative suport for sending exploded seriesKonstantin Ryabitsev
I've been working on a way to automatically convert pull requests into series, complete with mailing them out to arbitrary destinations. This would allow folks to send a pull request to a dedicated list and have it automatically converted into a well-formed series. This is a tentative implementation that relies on git-send-email to do most of the heavy lifting. I have misgivings about using git-send-email for this purpose, but it does reduce the amount of duplicated code we would have otherwise had to write, and allows us to hook into things like tocmd/cccmd, etc. For example, adding the following to your .git/config: [sendemail "autopr"] smtpserver = [your.server.here] smtpserverport = 587 smtpencryption = tls smtpuser = [your-user] smtppass = [your-pass] transferEncoding = 8bit suppressFrom = yes confirm = never validate = no tocmd = "$(git rev-parse --show-toplevel)/scripts/get_maintainer.pl --norolestats --nol" cccmd = "$(git rev-parse --show-toplevel)/scripts/get_maintainer.pl --norolestats --nom" This would allow doing the following: b4 pr -e -f "AutoPR Exploder <autopr@yourdomain.here>" -s autopr [--dry-run] The pull request will be exploded into a patch series and sent to all the proper destinations as returned by get_maintainer.pl. We construct the message headers in a way that allow regular code review and "b4 am" usage after the auto-exploded series is sent out. If testing goes well, we'll implement this as a kernel.org service and then hook a similar implementation via Gitlab/Github. Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
2021-05-21Move --show-keys into its own kr subcommandKonstantin Ryabitsev
There will be more keyring operations supported in the future, probably, but for now just move the --show-keys subcommand from "mbox" to "kr". Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
2021-05-18Don't use mboxo for anythingKonstantin Ryabitsev
While trying to figure out some odd DKIM failures, I've discovered that there is an important incompatibility between git's idea of what "mbox" format is, and Python's mboxo implementation -- at least when it comes to treating "\nFrom " escapes. According to the "original mbox" standard, when a message body contains a "\nFrom " sequence, it should be converted to "\n>From " in order not to confuse the parser. When reading messages in that format, clients are supposed to back-convert "\n>From " into their original form. This is the so-called "mboxo" format, which is what Python's mailbox.mbox supports: https://docs.python.org/3/library/mailbox.html#mailbox.mbox The "mboxrd" format was created to avoid a corruption problem whereas a body that legitimately contains "\n>From " would be wrongly converted into "\nFrom " upon parsing the mailbox, so mboxrd standard requires that, when saving a mailbox, "\n>From " sequences are additionally escaped as "\n>>From ". This is the format public-inbox supports, so when we grab mailboxes from remote, they are in mboxrd format. Git will try to guess the format of the mbox file, but it will ONLY back-convert "\n>From " sequences when you specifically tell it that it's "mboxrd" format, even when it's in fact "mboxo": git am --patch-format=mboxrd If you don't force the mboxrd format, git-am will preserve all escaped "\n>From " lines as-is. We've been previously operating on the assumption that git-am's mbox support properly implements "mboxo", but this was wrong, resulting in some commits like the following: https://git.kernel.org/torvalds/c/137733d08f4a This large-ish change ditches all internal use of Python's mboxo. When asked to save mbox files, we will save them without any escaping, the way git-am (i.e. git-mailsplit) espects them. The same goes when we're outputting to stdout. There is also a way now to pass -M to both "b4 am" and "b4 mbox" that will save things as maildirs -- git-am supports this natively and thus avoids any possible parsing ambiguities. You can set a config option b4.save-maildirs=yes to make this the default behaviour. The fallout of this is fairly benign, if annoying. There is no situation in which a patch would have "\nFrom " as part of its body, so the problem only affected commit messages. We will have a handful of these sprinkled around the trees, and will hopefully not introduce any new ones once everyone switches to the b4 version that outputs things in the format git-am expects. Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
2021-05-17Allow passing entire mbox via stdinKonstantin Ryabitsev
Per request, allow passing entire mbox files via stdin, allowing fully pipe-through operation from something like mutt: b4 am -sl -m - -o - Suggested-by: Peter Zijlstra <peterz@infradead.org> Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org> Link: https://lore.kernel.org/tools/YFETLu8TKWI2WlSF@hirez.programming.kicks-ass.net
2021-05-17Implement partial rerollKonstantin Ryabitsev
It has been a common request to support partial series rerolls where someone sends an amended patch as a follow-up to a previous series, e.g.: [PATCH v3 1/3] Patch one [PATCH v3 2/3] Patch two \- Re: [PATCH v3 2/3] Patch two Looks good, but please fix this $small_thing \- [PATCH v4 2/3] Patch two [PATCH v3] Patch three Previously, b4 refused to consider v4 as a complete new series, but now it will properly perform a partial reroll, but only in the cases where such patches are sent as follow-ups to the exact same patch number in the previous series: [PATCH v3->v4 1/3] Patch one [PATCH v4 2/3] Patch two [PATCH v3->v4 3/3] Patch three Reported-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org> Link: https://lore.kernel.org/r/CAPcyv4ggbuHbqKV33_TpE7pqxvRag34baJrX3yQe-jXOikoATQ@mail.gmail.com
2021-05-11Rudimentary support for showing patatt key infoKonstantin Ryabitsev
I expect that we'll have better keyring management tooling in the future, but for now show some rudimentary information about patatt keys used in a thread via --show-keys, e.g.: b4 mbox --show-keys 20210511143536.743919-1-konstantin@linuxfoundation.org b4 mbox --show-keys 20210507181322.172569-1-konstantin@linuxfoundation.org Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
2021-05-11Reimplement attestation code one more timeKonstantin Ryabitsev
Move end-to-end attestation code into its own library: patatt. See https://git.kernel.org/pub/scm/utils/patatt/patatt.git/about/ It is included into b4 as a submodule, but you will need to init it first: git submodule update --init This change significantly simplifies our attestation code, dropping thousands of lines of rather hairy code. Notably, patatt-style attestation is incompatible with previous attestation implementations done directly in b4, but that's just as well -- we've always marked it as "experimental" and the lack of adoption was proving that we weren't on the right path. Next to come is keyring management and documentation. Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
2020-12-21Add -f to "b4 mbox" to filter dupesKonstantin Ryabitsev
When saving to a maildir, add option to filter out dupes. Note, that this requires going through the entire maildir to collect message-ids, so it's not going to be a great experience on large maildirs. Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
2020-12-14Fix crasher when we don't use -g with b4 prKonstantin Ryabitsev
If we're not passing -g to "b4 pr -e", then we should try to see if we are inside a git checkout and use that as our source. Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
2020-12-11Rework b4 pr exploder for transparency log needsKonstantin Ryabitsev
Two services we'll be running in the near future: 1. Transparency log for all pull requests 2. Auto-exploder for pull requests that can send auto-exploded patches to all the same recipients. This requires quite a bit more testing and refinement, but the core of the functionality is there. Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
2020-11-24Add --cc-trailers option to b4 amKonstantin Ryabitsev
By request, add ability to copy all addresses from the email's "Cc" header into Cc: trailers, unless they are already mentioned in some other trailer. Requested-by: Arnaldo Carvalho de Melo <acme@kernel.org> Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
2020-11-23Add mutt-filter modeKonstantin Ryabitsev
Only works for x-patch-sig style attestation, as doing DKIM attestation requires that we unignore all headers, which just junks up the view. Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
2020-11-17Remove standalone attverify commandKonstantin Ryabitsev
We're only doing this as part of b4 am now, so remove the obsolete attverify command. Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
2020-10-02Reimplement attestation for in-header hashesKonstantin Ryabitsev
Rewrite attestation to implement in-header hashing and signing. For now, just implementing mode=pgp, but other modes are coming next. Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
2020-05-28Add --no-cover and -o - to output to stdoutKonstantin Ryabitsev
By request, provide a way to output the results of b4 am to stdout. This way it can be piped straight to "git am". E.g.: b4 diff 20200526205322.23465-1-mic@digikod.net -o - | git am Requested-by: Rob Herring <robh@kernel.org> Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
2020-05-25Add -3 to "b4 am" to prep for a 3way mergeKonstantin Ryabitsev
The original code used for b4 diff was to prepare for a 3-way merge by making sure that all blob indexes exist in the local repo. Add this functionality to "b4 am" and document all the features added in the 0.5.0 branch. Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
2020-05-22Add ability to diff arbitrary mbox filesKonstantin Ryabitsev
Sometimes we are unable to properly look up previous series -- usually because the cover letter title changes. For those cases, it is now possible to diff two arbitrary mbox files prepared with "b4 am -T". There's also a smattering of other fixes in there because I'm too lazy to properly stage my patches. Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
2020-05-19Display range-diff by defaultKonstantin Ryabitsev
Don't make developers do copy-pasting unnecessarily. Switch to outputting the diff by default, with flag options to save to file or just show what needs to be done. Additionally, adds caching to lookups and remember previously generated fake-am ranges so we don't continuously generate loose objects on repeat runs. Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
2020-05-15Initial implementation of b4 diffKonstantin Ryabitsev
Based on feedback from Jason Gunthorpe, implement diffing of series by creating fake git-am commit ranges. Here's an easy example: b4 diff 20200511192156.1618284-1-mic@digikod.net Suggested-by: Jason Gunthorpe <jgg@ziepe.ca> Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
2020-05-15Expand use of --cherry-pick ("this", globbing)Konstantin Ryabitsev
In addition to numerical ranges, -P is now also able to do: - "-P _" to grab just the msgid used with "b4 am" - "-P *glob*" to filter by commit message subject Suggested-by: Rob Herring <robh@kernel.org> Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
2020-05-07Add -P,--cherry-pick option to "b4 am"Konstantin Ryabitsev
This lets someone select a subset of patches in a series, e.g.: b4 am -P 1-3,5,7- [msgid] Suggested-by: Heiko Stübner <heiko@sntech.de> Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
2020-05-07Switch ty -s and -d to allow friendly rangesKonstantin Ryabitsev
Instead of insisting that people put in specific numbers, allow them to specify ranges, such as: b4 ty -s 1-3,5,7- Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
2020-05-07Do not crash when thread is incompleteKonstantin Ryabitsev
Do not try to calculate indexes on a missing patch in an incomplete thread. Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
2020-04-24Prepare for 0.4.0 releaseKonstantin Ryabitsev
It's time to graduate to 0.4.0 with these features. Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
2020-04-15Changes to b4 ty based on developer feedbackKonstantin Ryabitsev
- Properly expand ~ and env vars like $HOME in template paths - Allow partial matching of series (with a warning) - Allow using remote branches with -b - Always fall back to subject matching for patches - Tweak to the summary output Suggested-by: Mark Brown <broonie@kernel.org> Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Generated by cgit. Colors based on the Modus themes.