b4 auto-thankanator landed in master

b4 auto-thankanator landed in master

[Konstantin Ryabitsev]

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>
----

Re: [kernel.org users] b4 auto-thankanator landed in master

[Mark Brown]

[-- 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 --]

Re: [kernel.org users] b4 auto-thankanator landed in master

[Konstantin Ryabitsev]

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

Re: [kernel.org users] b4 auto-thankanator landed in master

[Mark Brown]

[-- 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 --]

Re: [kernel.org users] b4 auto-thankanator landed in master

[Konstantin Ryabitsev]

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

Re: [kernel.org users] b4 auto-thankanator landed in master

[Mark Brown]

[-- 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 --]

Re: [kernel.org users] b4 auto-thankanator landed in master

[Konstantin Ryabitsev]

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

Re: [kernel.org users] b4 auto-thankanator landed in master

[Mark Brown]

[-- 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 --]

Re: [kernel.org users] b4 auto-thankanator landed in master

[Konstantin Ryabitsev]

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

Re: [kernel.org users] b4 auto-thankanator landed in master

[Mark Brown]

[-- 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 --]

Re: [kernel.org users] b4 auto-thankanator landed in master

[Konstantin Ryabitsev]

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