* b4 auto-thankanator landed in master
@ 2020-04-10 21:00 Konstantin Ryabitsev
2020-04-15 15:00 ` [kernel.org users] " Mark Brown
0 siblings, 1 reply; 11+ messages in thread
From: Konstantin Ryabitsev @ 2020-04-10 21:00 UTC (permalink / raw)
To: tools; +Cc: users
Hi, all:
Based on your feedback, I added an "auto-thankanator" mode to b4, which
will track your use of "b4 am" and "b4 pr" and create convenient
templated thank-you replies when you run "b4 ty".
Here's a screencast with a hands-on example:
https://asciinema.org/a/318493
I also have another example below.
Since it's an experimental feature, we just save a .thanks file instead
of sending it outright -- at least until there's a lot more testing.
However, if you have git-send-email set up, you can easily send that
.thanks file off:
git send-email *.thanks
You can just hit "enter" for the questions git-send-email will try to
ask you, as all addressee information will be taken from the message
itself.
You can also list all tracked series and pull requests using:
b4 ty -l
They can be deleted or sent manually using "b4 ty -d" and "b4 ty -s"
respectively (some sanity checking will be done before sending).
Please also see "b4 ty --help" for other flags.
I'd like to hear your feedback on how this feature can be improved.
Similarly, it's possible that "b4 pr" workflow does not match how most
people use it, so I would greatly appreciate any feedback on how that
feature can be improved as well.
If you would like to test these features out, the repository is here:
https://git.kernel.org/pub/scm/utils/b4/b4.git/
There's probably lots of bugs in "b4 ty", but "b4 am" should be stable
enough for daily use.
Best regards,
-K
---
Inline example:
$ b4 am -o/tmp 20200408152151.5780-1-christian.brauner@ubuntu.com
Looking up https://lore.kernel.org/r/20200408152151.5780-1-christian.brauner@ubuntu.com
Grabbing thread from lore.kernel.org
Analyzing 16 messages in the thread
---
Writing /tmp/20200408_christian_brauner_loopfs.mbx
[✓] [PATCH 1/8] kobject_uevent: remove unneeded netlink_ns check
[✓] [PATCH 2/8] loopfs: implement loopfs
[✓] [PATCH 3/8] loop: use ns_capable for some loop operations
[✓] [PATCH 4/8] kernfs: handle multiple namespace tags
[✓] [PATCH 5/8] kernfs: let objects opt-in to propagating from the initial namespace
[✓] [PATCH 6/8] genhd: add minimal namespace infrastructure
[✓] [PATCH 7/8] loopfs: start attaching correct namespace during loop_add()
[✓] [PATCH 8/8] loopfs: only show devices in their correct instance
---
[✓] Attestation-by: Christian Brauner <christian.brauner@ubuntu.com> (pgp: 91C61BC06578DCA2)
---
Total patches: 8
---
Cover: /tmp/20200408_christian_brauner_loopfs.cover
Link: https://lore.kernel.org/r/20200408152151.5780-1-christian.brauner@ubuntu.com
Base: 7111951b8d4973bda27ff663f2cf18b663d15b48
git checkout -b 20200408_christian_brauner_ubuntu_com 7111951b8d4973bda27ff663f2cf18b663d15b48
git am /tmp/20200408_christian_brauner_loopfs.mbx
$ git checkout -o loopfs 7111951b8d4973bda27ff663f2cf18b663d15b48
$ git am /tmp/20200408_christian_brauner_loopfs.mbx
$ (hack-hack-hack, review-review-review)
$ git checkout master
$ git merge loopfs master --signoff
If you made no changes to the patch contents at all, you can run
"b4 ty --auto" to find that patch series in the current branch:
$ b4 ty --auto
Auto-thankanating commits in master
Found 10 of your commits since 1.week
Calculating patch hashes, may take a moment...
Located: [PATCH 0/8] loopfs
---
Generating 1 thank-you letters
Writing: ./christian_brauner_ubuntu_com_patch_0_8_loopfs.thanks
---
You can now run:
git send-email ./*.thanks
The contents of christian_brauner_ubuntu_com_patch_0_8_loopfs.thanks are:
----
From: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
To: [skipped]
Cc: [skipped]
In-Reply-To: <20200408152151.5780-1-christian.brauner@ubuntu.com>
References: <20200408152151.5780-1-christian.brauner@ubuntu.com>
Subject: Re: [PATCH 0/8] loopfs
Message-Id: <158655148980.3824973.6760061710410126169.b4-ty@linuxfoundation.org>
On Wed, 8 Apr 2020 17:21:43 +0200, Christian Brauner wrote:
> Hey everyone,
>
> After having been pinged about this by various people recently here's loopfs.
>
> This implements loopfs, a loop device filesystem. It takes inspiration
> from the binderfs filesystem I implemented about two years ago and with
> which we had overall good experiences so far. Parts of it are also
> based on [3] but it's mostly a new, imho cleaner and more complete
> approach.
>
> [...]
Applied, thanks!
- kobject_uevent: remove unneeded netlink_ns check
https://git.kernel.org/mricon/c/d8f4e1e096
- loopfs: implement loopfs
https://git.kernel.org/mricon/c/e022b26012
- loop: use ns_capable for some loop operations
https://git.kernel.org/mricon/c/a45ab6b63c
- kernfs: handle multiple namespace tags
https://git.kernel.org/mricon/c/9ea3d700d0
- kernfs: let objects opt-in to propagating from the initial namespace
https://git.kernel.org/mricon/c/50b98ec6f6
- genhd: add minimal namespace infrastructure
https://git.kernel.org/mricon/c/d01bc5a1a6
- loopfs: start attaching correct namespace during loop_add()
https://git.kernel.org/mricon/c/be02c77ba6
- loopfs: only show devices in their correct instance
https://git.kernel.org/mricon/c/b5cce3ce8f
Best regards,
--
Konstantin Ryabitsev <konstantin@linuxfoundation.org>
----
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [kernel.org users] b4 auto-thankanator landed in master
2020-04-10 21:00 b4 auto-thankanator landed in master Konstantin Ryabitsev
@ 2020-04-15 15:00 ` Mark Brown
2020-04-15 16:57 ` Konstantin Ryabitsev
0 siblings, 1 reply; 11+ messages in thread
From: Mark Brown @ 2020-04-15 15:00 UTC (permalink / raw)
To: Konstantin Ryabitsev; +Cc: tools
[-- Attachment #1: Type: text/plain, Size: 1126 bytes --]
On Fri, Apr 10, 2020 at 05:00:56PM -0400, Konstantin Ryabitsev wrote:
> Based on your feedback, I added an "auto-thankanator" mode to b4, which
> will track your use of "b4 am" and "b4 pr" and create convenient
> templated thank-you replies when you run "b4 ty".
Nice, this solves some problems I've been having with my scripts since
converting to b4!
It seems like this relies on git branch --show-current which isn't
supported by the git in Debian stable, 2.20.1. The documentation also
says that
b4 ty -s all
will send everything but it looks like that just lists all the tracked
patches instead (possibly because of the above, I didn't check). I'm
not sure what it's looking at the current branch for but if it's doing
that it'd be good to be able to tell it to look at a specific branch
instead -
> Since it's an experimental feature, we just save a .thanks file instead
> of sending it outright -- at least until there's a lot more testing.
It would be good if there was an explicit command for this, it'd be
useful when scripting stuff I think and also when testing things out.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 499 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [kernel.org users] b4 auto-thankanator landed in master
2020-04-15 15:00 ` [kernel.org users] " Mark Brown
@ 2020-04-15 16:57 ` Konstantin Ryabitsev
2020-04-15 17:23 ` Mark Brown
0 siblings, 1 reply; 11+ messages in thread
From: Konstantin Ryabitsev @ 2020-04-15 16:57 UTC (permalink / raw)
To: Mark Brown; +Cc: tools
On Wed, Apr 15, 2020 at 04:00:00PM +0100, Mark Brown wrote:
> On Fri, Apr 10, 2020 at 05:00:56PM -0400, Konstantin Ryabitsev wrote:
>
> > Based on your feedback, I added an "auto-thankanator" mode to b4, which
> > will track your use of "b4 am" and "b4 pr" and create convenient
> > templated thank-you replies when you run "b4 ty".
>
> Nice, this solves some problems I've been having with my scripts since
> converting to b4!
Thanks for testing it out! I'm sure there will be quite a few iterations
before I get the b4 ty workflow to the stage that is useful to most
maintainers.
> It seems like this relies on git branch --show-current which isn't
> supported by the git in Debian stable, 2.20.1.
Bah, I should check manpages more carefully. I switched to a more
generic alternative:
git rev-parse --abbrev-ref HEAD
> The documentation also says that
>
> b4 ty -s all
>
> will send everything but it looks like that just lists all the tracked
> patches instead (possibly because of the above, I didn't check).
I think I just forgot to add "all" handling to -s. :) It's fixed now.
> I'm
> not sure what it's looking at the current branch for but if it's doing
> that it'd be good to be able to tell it to look at a specific branch
> instead -
You can already do this by passing -b to "b4 ty":
b4 ty -b branchname
> > Since it's an experimental feature, we just save a .thanks file instead
> > of sending it outright -- at least until there's a lot more testing.
>
> It would be good if there was an explicit command for this, it'd be
> useful when scripting stuff I think and also when testing things out.
Eventually, the plan is to look into gitconfig for "sendemail"
configuration and use that for sending out email directly. For the
moment, you can achieve similar results by passing "--confirm=never" to
git send-email, which should just send the emails out.
I found a few more problems while testing things out, which highlighted
the need to use more forgiving patch hashing routines. Since I was
planning on integrating b4 with some of the patchwork automation
functionality in the near future anyway, I switched the tracking
routines to use patchwork-compatible patch hashes. Unfortunately, this
means that --auto will fail to properly work (since we changed the
hashes we use to track them). Things should still work with "b4 ty -s",
as we do matching by subject there when exact patch hashes fail.
Please update to the latest master and see if you have an easier time
with this feature.
Thanks again,
-K
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [kernel.org users] b4 auto-thankanator landed in master
2020-04-15 16:57 ` Konstantin Ryabitsev
@ 2020-04-15 17:23 ` Mark Brown
2020-04-15 17:55 ` Konstantin Ryabitsev
0 siblings, 1 reply; 11+ messages in thread
From: Mark Brown @ 2020-04-15 17:23 UTC (permalink / raw)
To: Konstantin Ryabitsev; +Cc: tools
[-- Attachment #1: Type: text/plain, Size: 4839 bytes --]
On Wed, Apr 15, 2020 at 12:57:12PM -0400, Konstantin Ryabitsev wrote:
> On Wed, Apr 15, 2020 at 04:00:00PM +0100, Mark Brown wrote:
> > On Fri, Apr 10, 2020 at 05:00:56PM -0400, Konstantin Ryabitsev wrote:
> > It seems like this relies on git branch --show-current which isn't
> > supported by the git in Debian stable, 2.20.1.
> Bah, I should check manpages more carefully. I switched to a more
> generic alternative:
> git rev-parse --abbrev-ref HEAD
That seems to work, thanks!
> > The documentation also says that
> > b4 ty -s all
> > will send everything but it looks like that just lists all the tracked
> > patches instead (possibly because of the above, I didn't check).
> I think I just forgot to add "all" handling to -s. :) It's fixed now.
That seemed to work however I immediately ran into:
Generating 1 thank-you letters
Traceback (most recent call last):
File "/home/broonie/git/b4/b4/command.py", line 198, in <module>
cmd()
File "/home/broonie/git/b4/b4/command.py", line 182, in cmd
cmdargs.func(cmdargs)
File "/home/broonie/git/b4/b4/command.py", line 60, in cmd_ty
b4.ty.main(cmdargs)
File "/home/broonie/git/b4/b4/ty.py", line 501, in main
send_selected(cmdargs)
File "/home/broonie/git/b4/b4/ty.py", line 411, in send_selected
send_messages(listing, cmdargs.gitdir, cmdargs.outdir, wantbranch, cmdargs.since)
File "/home/broonie/git/b4/b4/ty.py", line 321, in send_messages
signature = '%s <%s>' % (usercfg['name'], usercfg['email'])
KeyError: 'name'
git itself manages to figure out my name from passwd.
> > I'm
> > not sure what it's looking at the current branch for but if it's doing
> > that it'd be good to be able to tell it to look at a specific branch
> > instead -
> You can already do this by passing -b to "b4 ty":
> b4 ty -b branchname
Ah, great.
> > > Since it's an experimental feature, we just save a .thanks file instead
> > > of sending it outright -- at least until there's a lot more testing.
> > It would be good if there was an explicit command for this, it'd be
> > useful when scripting stuff I think and also when testing things out.
> Eventually, the plan is to look into gitconfig for "sendemail"
> configuration and use that for sending out email directly. For the
> moment, you can achieve similar results by passing "--confirm=never" to
> git send-email, which should just send the emails out.
That's the opposite of what I'm asking for - what I meant to say was
that I find the current behaviour useful and it'd be good to keep it
around even when b4 can send directly.
> I found a few more problems while testing things out, which highlighted
> the need to use more forgiving patch hashing routines. Since I was
> planning on integrating b4 with some of the patchwork automation
> functionality in the near future anyway, I switched the tracking
> routines to use patchwork-compatible patch hashes. Unfortunately, this
> means that --auto will fail to properly work (since we changed the
> hashes we use to track them). Things should still work with "b4 ty -s",
> as we do matching by subject there when exact patch hashes fail.
I think there's still some issue, not sure what triggers it but it seems
to happen with explicitly specified messages too. Do I need to clear
out some local database?
Calculating patch hashes, may take a moment...
Traceback (most recent call last):
File "/home/broonie/git/b4/b4/command.py", line 198, in <module>
cmd()
File "/home/broonie/git/b4/b4/command.py", line 182, in cmd
cmdargs.func(cmdargs)
File "/home/broonie/git/b4/b4/command.py", line 60, in cmd_ty
b4.ty.main(cmdargs)
File "/home/broonie/git/b4/b4/ty.py", line 501, in main
send_selected(cmdargs)
File "/home/broonie/git/b4/b4/ty.py", line 411, in send_selected
send_messages(listing, cmdargs.gitdir, cmdargs.outdir, wantbranch, cmdargs.since)
File "/home/broonie/git/b4/b4/ty.py", line 336, in send_messages
msg = generate_am_thanks(gitdir, jsondata, branch, since)
File "/home/broonie/git/b4/b4/ty.py", line 248, in generate_am_thanks
commits = auto_locate_series(gitdir, jsondata, branch, since, loose=True)
File "/home/broonie/git/b4/b4/ty.py", line 169, in auto_locate_series
commits = get_all_commits(gitdir, branch, since)
File "/home/broonie/git/b4/b4/ty.py", line 161, in get_all_commits
pwhash = b4.LoreMessage.get_patchwork_hash(out)
File "/home/broonie/git/b4/b4/__init__.py", line 822, in get_patchwork_hash
diff = LoreMessage.get_clean_diff(diff)
File "/home/broonie/git/b4/b4/__init__.py", line 879, in get_clean_diff
pp = int(plines)
TypeError: int() argument must be a string, a bytes-like object or a number, not 'NoneType'
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 499 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [kernel.org users] b4 auto-thankanator landed in master
2020-04-15 17:23 ` Mark Brown
@ 2020-04-15 17:55 ` Konstantin Ryabitsev
2020-04-15 18:32 ` Mark Brown
0 siblings, 1 reply; 11+ messages in thread
From: Konstantin Ryabitsev @ 2020-04-15 17:55 UTC (permalink / raw)
To: Mark Brown; +Cc: tools
On Wed, Apr 15, 2020 at 06:23:24PM +0100, Mark Brown wrote:
> > I think I just forgot to add "all" handling to -s. :) It's fixed
> > now.
>
> That seemed to work however I immediately ran into:
>
> Generating 1 thank-you letters
> Traceback (most recent call last):
> File "/home/broonie/git/b4/b4/command.py", line 198, in <module>
> cmd()
> File "/home/broonie/git/b4/b4/command.py", line 182, in cmd
> cmdargs.func(cmdargs)
> File "/home/broonie/git/b4/b4/command.py", line 60, in cmd_ty
> b4.ty.main(cmdargs)
> File "/home/broonie/git/b4/b4/ty.py", line 501, in main
> send_selected(cmdargs)
> File "/home/broonie/git/b4/b4/ty.py", line 411, in send_selected
> send_messages(listing, cmdargs.gitdir, cmdargs.outdir, wantbranch, cmdargs.since)
> File "/home/broonie/git/b4/b4/ty.py", line 321, in send_messages
> signature = '%s <%s>' % (usercfg['name'], usercfg['email'])
> KeyError: 'name'
>
> git itself manages to figure out my name from passwd.
Good to know. I committed a change that will do the same.
>
> > > It would be good if there was an explicit command for this, it'd be
> > > useful when scripting stuff I think and also when testing things out.
>
> > Eventually, the plan is to look into gitconfig for "sendemail"
> > configuration and use that for sending out email directly. For the
> > moment, you can achieve similar results by passing "--confirm=never" to
> > git send-email, which should just send the emails out.
>
> That's the opposite of what I'm asking for - what I meant to say was
> that I find the current behaviour useful and it'd be good to keep it
> around even when b4 can send directly.
Ah, right, we'll probably always default to just writing out the thanks
files and will only send when specifically told to do so -- i.e. exactly
what you're looking for.
> > I found a few more problems while testing things out, which
> > highlighted the need to use more forgiving patch hashing routines.
> > Since I was planning on integrating b4 with some of the patchwork
> > automation functionality in the near future anyway, I switched the
> > tracking routines to use patchwork-compatible patch hashes.
> > Unfortunately, this means that --auto will fail to properly work
> > (since we changed the hashes we use to track them). Things should
> > still work with "b4 ty -s", as we do matching by subject there when
> > exact patch hashes fail.
>
> I think there's still some issue, not sure what triggers it but it seems
> to happen with explicitly specified messages too. Do I need to clear
> out some local database?
No, this means we're getting an output that I'm not expecting. Could you
please rerun that as "b4 -d" to enable debug output? Right before it
crashes, it should print out a line like this:
Running git --no-pager diff ...
I'd be very interested to see the diff that is produced by running that
command (specifically, the @@ @@ lines). That code currently expects to
always have lines added and lines removed, but that appears to be the
wrong expectation and I need to fix that.
-K
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [kernel.org users] b4 auto-thankanator landed in master
2020-04-15 17:55 ` Konstantin Ryabitsev
@ 2020-04-15 18:32 ` Mark Brown
2020-04-15 19:28 ` Konstantin Ryabitsev
0 siblings, 1 reply; 11+ messages in thread
From: Mark Brown @ 2020-04-15 18:32 UTC (permalink / raw)
To: Konstantin Ryabitsev; +Cc: tools
[-- Attachment #1: Type: text/plain, Size: 1312 bytes --]
On Wed, Apr 15, 2020 at 01:55:48PM -0400, Konstantin Ryabitsev wrote:
> On Wed, Apr 15, 2020 at 06:23:24PM +0100, Mark Brown wrote:
> > I think there's still some issue, not sure what triggers it but it seems
> > to happen with explicitly specified messages too. Do I need to clear
> > out some local database?
> No, this means we're getting an output that I'm not expecting. Could you
> please rerun that as "b4 -d" to enable debug output? Right before it
> crashes, it should print out a line like this:
> Running git --no-pager diff ...
> I'd be very interested to see the diff that is produced by running that
> command (specifically, the @@ @@ lines). That code currently expects to
> always have lines added and lines removed, but that appears to be the
> wrong expectation and I need to fix that.
Running git --no-pager diff d2a66a4f85813d53fa5618f95e365a4f3beb2aa3~..d2a66a4f85813d53fa5618f95e365a4f3beb2aa3
is the one immediately before it explodes. That's a local commit in my
tree which I'm reluctant to share but playing about a bit I'm pretty
sure that the issue is that the only thing it does is add a file - the
one @@ line is:
@@ -0,0 +1 @@
and I can reproduce similar behaviour with other random one line
additions. Does that help you see the issue?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 499 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [kernel.org users] b4 auto-thankanator landed in master
2020-04-15 18:32 ` Mark Brown
@ 2020-04-15 19:28 ` Konstantin Ryabitsev
2020-04-15 20:12 ` Mark Brown
0 siblings, 1 reply; 11+ messages in thread
From: Konstantin Ryabitsev @ 2020-04-15 19:28 UTC (permalink / raw)
To: Mark Brown; +Cc: tools
On Wed, Apr 15, 2020 at 07:32:48PM +0100, Mark Brown wrote:
> > I'd be very interested to see the diff that is produced by running
> > that command (specifically, the @@ @@ lines). That code currently
> > expects to always have lines added and lines removed, but that
> > appears to be the wrong expectation and I need to fix that.
>
> Running git --no-pager diff d2a66a4f85813d53fa5618f95e365a4f3beb2aa3~..d2a66a4f85813d53fa5618f95e365a4f3beb2aa3
>
> is the one immediately before it explodes. That's a local commit in my
> tree which I'm reluctant to share but playing about a bit I'm pretty
> sure that the issue is that the only thing it does is add a file - the
> one @@ line is:
>
> @@ -0,0 +1 @@
>
> and I can reproduce similar behaviour with other random one line
> additions. Does that help you see the issue?
Yes, we always expect there to be a N,N in that output, which isn't true
in a number of scenarios (like a commit that creates a new file with
only one line).
The latest master should properly deal with this situation (as well as
when a patch deletes all lines from a file).
Glad you ran across this, as this affects attestation as well. Looks
like I'll need to backport that to 0.3.y.
Thanks,
-K
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [kernel.org users] b4 auto-thankanator landed in master
2020-04-15 19:28 ` Konstantin Ryabitsev
@ 2020-04-15 20:12 ` Mark Brown
2020-04-15 21:21 ` Konstantin Ryabitsev
0 siblings, 1 reply; 11+ messages in thread
From: Mark Brown @ 2020-04-15 20:12 UTC (permalink / raw)
To: Konstantin Ryabitsev; +Cc: tools
[-- Attachment #1: Type: text/plain, Size: 1687 bytes --]
On Wed, Apr 15, 2020 at 03:28:19PM -0400, Konstantin Ryabitsev wrote:
> On Wed, Apr 15, 2020 at 07:32:48PM +0100, Mark Brown wrote:
> > and I can reproduce similar behaviour with other random one line
> > additions. Does that help you see the issue?
> Yes, we always expect there to be a N,N in that output, which isn't true
> in a number of scenarios (like a commit that creates a new file with
> only one line).
> The latest master should properly deal with this situation (as well as
> when a patch deletes all lines from a file).
Did you forget to push...
> Glad you ran across this, as this affects attestation as well. Looks
> like I'll need to backport that to 0.3.y.
...I'm seeing a relevant update on 0.3.y but master has c4469dc30c30f6
(Keep track of how many messages we create) as the head still.
I also noticed a couple of other issues.
One is that if I try to specify a remote branch with 'b4 ty -s all -b
remote/foo' or whatever b4 doesn't think the branch exists. I'm doing
this because I want to be sure I only send out thank you mails for
things that actually got pushed successfully (in the past I've found
people get confused if the thanks arrives and they can't see the
published commit). It needs a --remote on the git branch command line.
The other is that if I don't apply all of a series then b4 ty will
refuse to generate anything with no way I can see to override. This
happens a fair amount when people do things like send a new driver along
with a DT update. Perhaps an option to allow partial lists (though I
think that might need more complex templating), or one to generate
per-patch thanks messages?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 499 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [kernel.org users] b4 auto-thankanator landed in master
2020-04-15 20:12 ` Mark Brown
@ 2020-04-15 21:21 ` Konstantin Ryabitsev
2020-04-15 21:40 ` Mark Brown
0 siblings, 1 reply; 11+ messages in thread
From: Konstantin Ryabitsev @ 2020-04-15 21:21 UTC (permalink / raw)
To: Mark Brown; +Cc: tools
On Wed, Apr 15, 2020 at 09:12:22PM +0100, Mark Brown wrote:
> > Yes, we always expect there to be a N,N in that output, which isn't
> > true in a number of scenarios (like a commit that creates a new file
> > with only one line).
>
> > The latest master should properly deal with this situation (as well as
> > when a patch deletes all lines from a file).
>
> Did you forget to push...
Haha, classic. Yes, it should be there now.
> I also noticed a couple of other issues.
>
> One is that if I try to specify a remote branch with 'b4 ty -s all -b
> remote/foo' or whatever b4 doesn't think the branch exists. I'm doing
> this because I want to be sure I only send out thank you mails for
> things that actually got pushed successfully (in the past I've found
> people get confused if the thanks arrives and they can't see the
> published commit). It needs a --remote on the git branch command line.
Right, we're only paying attention to local branches right now. I'll
poke to see what needs to happen to work for remotes.
> The other is that if I don't apply all of a series then b4 ty will
> refuse to generate anything with no way I can see to override.
I think the master has a change for that as well -- try that out.
> This
> happens a fair amount when people do things like send a new driver along
> with a DT update. Perhaps an option to allow partial lists (though I
> think that might need more complex templating), or one to generate
> per-patch thanks messages?
I think we can do --partial. Let me ponder how that can be done best.
Thanks,
-K
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [kernel.org users] b4 auto-thankanator landed in master
2020-04-15 21:21 ` Konstantin Ryabitsev
@ 2020-04-15 21:40 ` Mark Brown
2020-04-15 22:36 ` Konstantin Ryabitsev
0 siblings, 1 reply; 11+ messages in thread
From: Mark Brown @ 2020-04-15 21:40 UTC (permalink / raw)
To: Konstantin Ryabitsev; +Cc: tools
[-- Attachment #1: Type: text/plain, Size: 1123 bytes --]
On Wed, Apr 15, 2020 at 05:21:02PM -0400, Konstantin Ryabitsev wrote:
> On Wed, Apr 15, 2020 at 09:12:22PM +0100, Mark Brown wrote:
> > Did you forget to push...
> Haha, classic. Yes, it should be there now.
It is and works, thanks!
> > The other is that if I don't apply all of a series then b4 ty will
> > refuse to generate anything with no way I can see to override.
> I think the master has a change for that as well -- try that out.
> > This
> > happens a fair amount when people do things like send a new driver along
> > with a DT update. Perhaps an option to allow partial lists (though I
> > think that might need more complex templating), or one to generate
> > per-patch thanks messages?
> I think we can do --partial. Let me ponder how that can be done best.
That should work for me, and be able to replace my own thanks generating
scripts which will make some of the people who get those mails happy!
One more issue - if I set b4.thanks-XX-template with a path based off ~
then b4 won't expand the ~, it needs a fully qualified (or I guess
relative, didn't check) path.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 499 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [kernel.org users] b4 auto-thankanator landed in master
2020-04-15 21:40 ` Mark Brown
@ 2020-04-15 22:36 ` Konstantin Ryabitsev
0 siblings, 0 replies; 11+ messages in thread
From: Konstantin Ryabitsev @ 2020-04-15 22:36 UTC (permalink / raw)
To: Mark Brown; +Cc: tools
On Wed, Apr 15, 2020 at 10:40:01PM +0100, Mark Brown wrote:
> > I think we can do --partial. Let me ponder how that can be done
> > best.
>
> That should work for me, and be able to replace my own thanks generating
> scripts which will make some of the people who get those mails happy!
>
> One more issue - if I set b4.thanks-XX-template with a path based off ~
> then b4 won't expand the ~, it needs a fully qualified (or I guess
> relative, didn't check) path.
I implemented most of your feedback in the latest commit to master. We
now always allow partial matching, but will give a warning that the
message should be reviewed. You should also be able to pass remote
branches to -b (remotename/branchname).
Please try it out and keep all the suggestions coming. :)
Best,
-K
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2020-04-15 22:36 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-04-10 21:00 b4 auto-thankanator landed in master Konstantin Ryabitsev
2020-04-15 15:00 ` [kernel.org users] " Mark Brown
2020-04-15 16:57 ` Konstantin Ryabitsev
2020-04-15 17:23 ` Mark Brown
2020-04-15 17:55 ` Konstantin Ryabitsev
2020-04-15 18:32 ` Mark Brown
2020-04-15 19:28 ` Konstantin Ryabitsev
2020-04-15 20:12 ` Mark Brown
2020-04-15 21:21 ` Konstantin Ryabitsev
2020-04-15 21:40 ` Mark Brown
2020-04-15 22:36 ` Konstantin Ryabitsev
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.