From Oliver Lowe to ~andrewrk/ziglang
Found this in-progress ticket: https://github.com/ziglang/zig/issues/8755 So it seems like it's not possible (yet!)
From Oliver Lowe to ~sircmpwn/sr.ht-discuss
Had a quick look at the test repository and was curious how git(1) itself behaves: $ echo '' >> broken.pdf $ echo '' >> works.pdf $ git diff diff --git a/broken.pdf b/broken.pdf index 9c04837..6aefa42 100644 --- a/broken.pdf +++ b/broken.pdf @@ -773,3 +773,4 @@ trailer startxref 27975 %%EOF
From Oliver Lowe to ~yana/cl-lemmy-api
--- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 5669ff4..f303e0b 100644 --- a/README.md +++ b/README.md @@ -6,7 +6,7 @@ Lemmy API interfaces, methods, enums, and types are defined according to the reference JS client implementation. The main project page is available at https://sr.ht/~yana/cl-lemmy-api/. Bugs may be reported at https://todo.sr.ht/~yana/cl-lemmy-api. may be reported at https://todo.sr.ht/~yana/cl-lemmy-api/.[message trimmed]
From Oliver Lowe to ~sircmpwn/email-test-drive
--- myname1234 | 1 + 1 file changed, 1 insertion(+) create mode 100644 myname1234 diff --git a/myname1234 b/myname1234 new file mode 100644 index 0000000..7fbef93 --- /dev/null +++ b/myname1234 @@ -0,0 +1 @@ \ No newline at end of file -- I have successfully used git send-email![message trimmed]
From Oliver Lowe to ~sircmpwn/email-test-drive
--- myname1234 | 1 + 1 file changed, 1 insertion(+) create mode 100644 myname1234 diff --git a/myname1234 b/myname1234 new file mode 100644 index 0000000..7a96fed --- /dev/null +++ b/myname1234 @@ -0,0 +1 @@ \ No newline at end of file -- I'm about to try git send-email![message trimmed]
From Oliver Lowe to ~sircmpwn/email-test-drive
--- myname1234 | 1 + 1 file changed, 1 insertion(+) create mode 100644 myname1234 diff --git a/myname1234 b/myname1234 new file mode 100644 index 0000000..4b5fa63 --- /dev/null +++ b/myname1234 @@ -0,0 +1 @@ -- 2.40.0 hello, world[message trimmed]
From Oliver Lowe to ~sircmpwn/sr.ht-discuss
This isn't a direct answer but here's an approach that may help: I try to keep logic out of CI/CD manifests. In other words, I aim for manifests to be a thin shim for other tooling like shell scripts and dedicated build tooling. I’ve joined a few projects struggling with CI/CD manifests of hundreds of lines over hundreds of repositories (Gitlab CI, Jenkins...). Debugging these was hard. The workflow reminded me of those stories older folks tell about submitting punch cards to some batch system and waiting for the result. Shrinking the manifests by pulling out logic into shell scripts and language-specific build/test tooling eased a lot of pain. From there, one can start running stuff locally. Faster feedback, easier debugging, static analysis, lots of pre-existing tooling and docs.
From Oliver Lowe to ~sircmpwn/sr.ht-discuss
> As you can see in my project [1] the summary is divided in > several lines. I think it's because you use `class="col-md-6"` in CSS. The text wraps because the area is divided into two sections: <div class="row"> <div class="col-md-6"> Go package for controlling a Starlink Dishy device </div> <div class="col-md-6 licenses"></div> </div> Maybe that space is reserved for a future feature where a short description of the project’s license is shown?
From Oliver Lowe to ~sircmpwn/sr.ht-discuss
> IMO it's better to track any shared config iside the repo for this > purpose. > > That's no less convenient than your proposal (either pick and copy > desired settings or include the config file(s) wholesale) and has some > advantages, too: it will work everywhere without any need for > server-side changes, and future updates will be propagated during next > pull (your proposal looks like a one-time thing during clone). Agreed; here’s a real world example. In my work I’m often under tight deadlines, so I’m often passing around tarballs of repositories (mercurial and git), then sending patches through email or chat. Files in the repository have long outlasted the different servers and outdated wikis. Getting write access to the servers can take weeks!
From Oliver Lowe to ~sircmpwn/sr.ht-discuss
On Sat, Oct 22, 2022 at 10:06:01AM +0200, Bastien wrote: > Would anyone find it useful to have a RSS feed for sr.ht mailing > lists? Yes! I thought about this recently. But not just for sr.ht; any mailing list! My idea was a utility I called mbox2atom. usage: mbox2atom [file ...] mbox2atom reads from the named mbox files (or the standard input if none specified), and writes a RFC4287 Atom feed to the standard output. From there I wanted to run it in cron(8) or something, then serve the files from any old HTTP server.