On 4/5/21 3:41 PM, Drew DeVault wrote:
> This is intended, yes. 

Thanks for the clarification.

> You should commit a proper fix upstream if you want to associate it
> with, well, the upstream project.

Well, the issue with the build[1] wasn't caused by an upstream change, 
though. That's why I resubmitted the build instead of committing 
something upstream.

1: see task "setup" line 3

For example, the following build failed because of what seems to be a 
sr.ht error:

	https://builds.sr.ht/~admicos/job/477851

I resubmitted the build from the button next to it, and it created this 
new job:

	https://builds.sr.ht/~admicos/job/477853

However, the second build is not listed under the same "project" as the 
first, which makes it hard to find:

	https://builds.sr.ht/~admicos/moonlander

The archive URLs are going to change in a week or so, as I'm working on
changing parts of the server hosting them, so this patch doesn't exactly
make sense to apply, at least for now.

I'd recommend you move what you want from my repo into somewhere else
you control. I haven't touched this repo (and Computercraft as a whole)
for a long time now, and I don't really see the point in keeping these
working.

--
Have a nice /(day|night|week(end)?)/
~ Ecmel B. Canlıer ~

Correct the [fonts.gemini] heading to [fonts.gemini.text] in the example
configuration shown in the README.md
---
 README.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/README.md b/README.md
index f04ae48..0839693 100644
--- a/README.md
+++ b/README.md
@@ -92,7 +92,7 @@ list = "🌼 "
 [fonts.finger]
     family = "monospace"
     size = 11
[message trimmed]

On most programs, I can use my mouse's side buttons to navigate back or
forward, while on Castor, the back button on top is the only way I can
navigate back to the previous page.

If you don't have a mouse with said side buttons, here are the button
events from both wev (Wayland) and xev (X.Org)

ps. I remember some mice I used swapped the buttons, though not
entirely sure on that.

pps. According to this[1] bug, GTK uses the xorg button ids (8, 9)
[1]: https://gitlab.gnome.org/GNOME/gtk/issues/515

ppps. Feel free to send a patch if you want testing

Yup! Everything works fine :)

---
 admicos-newmailhost | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 admicos-newmailhost

diff --git a/admicos-newmailhost b/admicos-newmailhost
new file mode 100644
index 0000000..66cb3d4
--- /dev/null
+++ b/admicos-newmailhost
@@ -0,0 +1 @@
+I have successfully used git send-email!
[message trimmed]

Just testing if my new mail host is configured for Git patches

---
 admicos-newmailhost | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 admicos-newmailhost

diff --git a/admicos-newmailhost b/admicos-newmailhost
new file mode 100644
index 0000000..b4380e4
--- /dev/null
+++ b/admicos-newmailhost
@@ -0,0 +1 @@
+I'm about to try git send-email!
[message trimmed]

On 7/29/19 7:10 PM, Drew DeVault wrote:
> The reason I didn't answer this is because it doesn't fit in the space
> allocated for these links - and I didn't really have a good solution.
> With your patch the caret-right gets pushed off the edge and ends up
> alone on the next line.
> 
That makes sense.

I'm not sure on how sensible this would be, but I could move it to the
"clone" column, under a new "tarball" header, like what GitHub does with
its "Clone or Download" button. But that definitely feels a little off.

Aside from that, I don't have any idea either.

Normally, only tags have tarball download links. This patch adds a
download link for the tarball of the default branch (eg master) to the
the repository summary page.

The link will be added next to the browse and log links.
---
I asked about implementing this in [1], but got no response. I still decided
to create this patch anyway, as it's a *very* simple change.

[1]: https://lists.sr.ht/~sircmpwn/sr.ht-discuss/%3Cf7af3c4e-ee62-95dd-a8fd-83fbd6a88ca7%40ecmelberk.com%3E

 gitsrht/templates/summary.html | 3 +++
 1 file changed, 3 insertions(+)
[message trimmed]

If I'm not missing anything, currently, you can only download tarballs 
via the web interface if the repo actually contains a tag.

I feel like this is a deliberate decision, but I'm not entirely sure 
why, and digging through the mailing lists didn't show any discussion 
about that.

The `/<owner>/<repo>/archive/<path:ref>.tar.gz` endpoint works on 
regular branches, and the summary page already seems to have a archive 
link for the latest tag anyway, so adding this feature would be as easy 
as adding another link for the branch archive itself.

I wouldn't mind sending a patch for this, just posting to see if there 
is a proper reason on why there isn't any link for the branch archive