On Wed, Jun 29, 2022 at 06:24:13PM +0200, Grzegorz Szymaszek wrote:
> The project mailing list link URL in the README.md was set to
> “mailto:~nabijaczleweli/klapki” — this email address lacks the
> domain part, which should be “lists.sr.ht”.
> ---
>  README.md | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Whoops; applied as 30dba7e0233b480677f75d9d9e76210a163185ce, thanks!

наб

On Mon, Jan 24, 2022 at 04:20:17PM +0100, Drew DeVault wrote:
> On Mon Jan 24, 2022 at 4:15 PM CET, наб wrote:
> > On Mon, Jan 24, 2022 at 03:39:37PM +0100, Drew DeVault wrote:
> > > Is this something that is better addressed in pygit2 upstream?
> > I don't... think so?
> >
> > Since this is the porcelain behaviour of the CLI
> > (I mean, technically it's probably the Normal behaviour for
> >  plain git blame, too, the chunk boundaries just aren't shown),
> > so I'm pretty sure this is expected for libgit2/pygit2 as well.
> It doesn't seem like the right behavior for the CLI, either, so perhaps
> it should go as far upstream as git itself. And if, on the other hand,
> it is the right behavior for git, perhaps it is also the right behavior
> for git.sr.ht?

On Mon, Jan 24, 2022 at 03:39:37PM +0100, Drew DeVault wrote:
> Is this something that is better addressed in pygit2 upstream?
I don't... think so?

Since this is the porcelain behaviour of the CLI
(I mean, technically it's probably the Normal behaviour for
 plain git blame, too, the chunk boundaries just aren't shown),
so I'm pretty sure this is expected for libgit2/pygit2 as well.

> On Sat Jan 22, 2022 at 9:36 PM CET, наб wrote:
> > These are split, like in porcelain mode in CLI, when consecutive final
> > commit lines are non-consecutive in the originals (I think?)
> >
> > Closes: https://todo.sr.ht/~sircmpwn/git.sr.ht/357

These are split, like in porcelain mode in CLI, when consecutive final
commit lines are non-consecutive in the originals (I think?)

Closes: https://todo.sr.ht/~sircmpwn/git.sr.ht/357
---
This turned out simpler than expected, and fixes the blame view from the
referenced issue

Can't just assign to the raw BlameHunks since that yields an
AttributeError

 gitsrht/blueprints/repo.py | 27 ++++++++++++++++++++++++++-
 1 file changed, 26 insertions(+), 1 deletion(-)
[message trimmed]

Documentation and source tarballs as well as the full changelog
can be obtained from
  https://git.sr.ht/~nabijaczleweli/yaxpeax-superh/refs/v1.0.0

And distributed on crates.io: https://crates.io/crates/yaxpeax-superh

As this is a major version bump, there is a breaking change:
all &[SuperHFeature]s were replaced with a SuperHFeatures bitflags,
and the decoders lost their lifetime parameters ‒ a patch from Noa.

On Tue, Jan 04, 2022 at 06:59:10PM -0600, Noa Oxer wrote:
> > Is there a less sucky way to write out the empty set?
> There are a couple different options - Default::default(), adding a `const
> EMPTY = 0` to the bitflags; what kind of thing were you thinking?
Something as succinct as [], but given that and a skim through the
bitflags docs, it doesn't seem like anything's better than just
::empty() in this case.

It also doesn't seem like bumping the flag size will break API in a
meaningful way.

Patch applied as 9eb0e4e58a420386dbb3400a976df1c0a78fbe83, thanks!

наб

On Tue, Jan 04, 2022 at 04:31:50PM -0600, ~coolreader18 wrote:
> diff --git a/src/lib.rs b/src/lib.rs
> index b06e887..a66de10 100644
> --- a/src/lib.rs
> +++ b/src/lib.rs
> @@ -1926,7 +1925,7 @@ impl<'f> yaxpeax_arch::Decoder<SuperH<'_>> for SuperHDecoder<'_> {
>              return Err(SuperHInstructionDecodeError::NotFound);
>          }
> 
> -        if !ret.features().iter().all(|rf| self.features.contains(rf)) {
> +        if !self.features.contains(ret.features()) {
>              return Err(SuperHInstructionDecodeError::NotFound);
>          }
I like how this turned out!

On Tue, Jan 04, 2022 at 10:38:57PM +0000, ~coolreader18 wrote:
> I'm not sure what the upper limit on the number of features might be, or
> if what's there now is what'll be there forever, so I just went with a
> u8 to hold the bitflags. There's room for 5 more features or it could be
> bumped to u16.
I'm not super-familiar with bitflags ‒ would that break API compatibility
or not?

наб

On Sat, Jan 01, 2022 at 10:45:40AM +0100, Drew DeVault wrote:
> NACK: maybe you should use script(1) for this?
Hm, non-interactive script(1) hasn't crossed my mind, but it does,
indeed, appear to work, and quite well at that (with the unsurprising
exception of OpenBSD, where it works but sucks ass; patches pending);
thanks!

---
Foolishly, I didn't look to see if this is inlined anywhere else;
this is the only remaining mention

 builds.sr.ht/index.md | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/builds.sr.ht/index.md b/builds.sr.ht/index.md
index 4e0cf48..58a6f8a 100644
--- a/builds.sr.ht/index.md
@@ -134,8 +134,12 @@ Each task's script is given a preamble that looks like this:
 ```sh
 #!/usr/bin/env bash
[message trimmed]