I didn’t see a single comment that crossed the line on being hostile but before leaving feedback on a post like this I’d urge you all to weigh two things: (1) the importance your feedback be heard vs (2) that feedback contributing to an environment that would make a person not do such work again in the future (or at least not announce it on this site).
Usually negative, constructive feedback is good but I don’t see how anyone could read this comments section and declare it useful.
This is something I’ve been hacking on for the past week or so, born out of my frustration with cgit being terrible to use on mobile. The default styling is somewhat opinionated, so you might want to change it up. Also available on GitHub, if that’s your thing.
Let me know if you have any trouble setting it up—I’ll be happy to help.
What are your thoughts on using it to front gitolite? That’s where I store my git repos, I like the user granularity, but I think I’d need to put an auth layer in front of this site to make it work right.
Shame I can’t use an ssh key for web authentication! (cue lots of people telling me how?)
I’m not the author, but I’ve also experimented with a stand-alone ssh git service which keeps all its keys in git (similar to how gitolite does). I’d love to go back to that, clean it up, and add a web-ui somehow as well…
You could probably do auth by having someone sign a random string with their git private key… or provide a command they can use with ssh to get a login token.
Cool project! I ended up with gitolite specifically because it used the system sshd so I could also log in to the server as me. Made administration easier.
Interesting idea, signing something with ssh to generates a login token… that could have merit, and be easy for automation (vault I think could generate the token as it expires and replace it on servers needing the token to be fresh)
I’m not sure if it’s still a thing, but that’s similar to one of the “second factors” we allowed for 2fa account recovery at Bitbucket - you could SSH in (and run a specific command) and it would count that as a login. I think when they migrated to Atlassian ID, that went away though.
No idea if I’ll find the time to work on it soon, but it could be interesting! We’ll have to see where it falls in terms of my personal project prioritization.
It’s fun to contrast the presentation of both these tools. While legit has a very calm, spacious layout (which I like), it’s not as immediate or easy to ready at a glance as stagit’s compressed, bare layout.
Can we stop the $tool written in $language type of headlines? It’s annoying. Yes write tools in whatever language you like. But give some other argument why this implementation is better then the rest. Because a skilled programmer can write horrible code in any language ;-)
I’m sorry you’re miffed by the headline—I too feel similarly about “written in Rust” posts. I think I just internalized the “foo, written in bar” format and wrote the headline like that. As for why this is better, I’ve briefly outlined it in the readme.
I don’t find this info unnecessary and it actually helps me decide to checkout a project. I am familiar with Go, so any project in Go gets my attention quickly. If the title didn’t mention the language, then first thing I would do is to check which language it is written in.
It’s a self hosting tool. Language and the tooling matters a lot to me.
Languages that compile to a binary also tell me something about the performance characteristics I can expect. I don’t know (and am not curious about) Go, but I know it will more than likely produce something pretty quick and light on resources. The self-hosting part is real too because you should be assured that you won’t need high-end hardware like hosting a Rails server.
Personally, that it’s written in go is more useful to me than written in node or written in java. It tells me a lot about the “handling characteristics” of the program from an operations standpoint, and that’s valuable.
Your readme starts with “A git web frontend written in Go” followed by a pronounce guide. Maybe try something like “A small, customizable git web frontend”.
FWIW, I am only interested in hacking on an OSS web app if it’s written in Go. As a developer I’m not really interested in ones written in other languages, although I will use them as a consumer. So for me “written in Go” is a useful bit of signal.
I think it’s pretty useful information to have in the readme as it informs the user of what language tooling they’d need to build/run this. I’m now convinced you didn’t read beyond the first few lines, or you’d have reached the “features” section which does briefly outline why this is better than the rest. In the context of this post alone, I’d even argue that there’s plenty to glean by simply using the site (since it’s also the software being discussed).
You are being given good feedback and your first instinct is to negate the feedback as fast as you can type out a response with your keyboard without taking a moment to reflect on it, compose yourself and evaluate the feedback on its own merits.
What’s worse is that you then go on to insinuate that the parent commenter did not even read beyond the first first few lines! How can you possibly know that? How can you be so convinced that someone else on the internet did not read your complete post? This is not how to run a successful project!
I did read your entire post and I find the parent comment to be 100% right! Your README starts with “A git web frontend written in Go.” Then the very next thing it explains is how to pronounce your project name!
And then your features list has these 4 things:
• Fully customizable templates and stylesheets.
• Cloning over http(s).
• Less archaic HTML.
• Not CGI.
What does it tell me? I don’t know. It’s a web-based tool. I can customize the templates. Fine. But why does it make it better? All web-based tools these days have customizable templates, right? Cloning over https(s). Sure. But why does it make it better than alternatives? What are the alternatives?
“Less archaic HTML.” What does that even mean? You mean no <table> for layout? Does it really need to be mentioned in a project created in 2022?
“No CGI”? Why tell us what it is not when you can simply tell us what it is? Maybe you mean to say that the web-server is built-in into the project (by virtue of Go net/http or one of its wrappers)? Maybe you mean to say that we can deploy it as a single binary? If that is what you want to say, just say that!
Sorry but I have to agree with the parent comment. If you communicate more directly what your project is and why we should care about it, you would capture my attention and some other folks too who you are turning away right now.
I would like to offer a counterpoint to these things:
“Written in go” is something that, as someone mostly outside the web bubble, I really appreciate when it’s about web tools. It tells me I can probably just go get this and run it, instead of setting up some Docker-based infernal machine that will take forever to build, take up half a gigabyte just to serve git repos, and require me to fiddle with my network setup just so I can get Docker running along with my VPN.
“Fully customizable templates and stylesheets”, “Cloning over http(s)”, “Not CGI” are all things that other existing git frontends suffer from. If you’ve used them before and researching for alternatives, you know why you would want some of these things. Listing them all is useful IMHO, because many of these are just matters of personal preference. There’s no universal justification for why they’re better (or worse).
This is not a commercial product, as far as I can tell, this doesn’t have to be an elevator pitch.
Personally, I like the current README. I think the information it offers is relevant for people who are looking for an alternative git web frontend.
Changing the description to some canned generic description (“light, customizable web-based git frontend”) would make it worse, that describes basically every frontend that doesn’t have a corporate licensing scheme.
Changing the rest of the README to list things that are relevant for everyone, not just people who are already familiar, but dissatisfied with existing git web frontends would be pretty counterproductive: these are literally the people who are probably interested in legit. Of course the README is written for them.
What does it tell me? I don’t know. It’s a web-based tool. I can customize the templates. Fine. But why does it make it better? All web-based tools these days have customizable templates, right?
No not all web based tools have customizable templates.
I think the author may be comparing their project against cgit’s featureset, which gives those points more context as to why they’re important to mention.
cgit is CGI based, has archaic HTML, and no customizable templates. It can clone over https and more though.
It’s clear then the README assumes the reader / user is familiar with other git frontends. If not then just ignore the project and move on or dive deeper…
you would capture my attention and some other folks too who you are turning away right now.
Our attention really means nothing, it’s a hobbyist project. They’re just sharing something they think others will be interested in. Really doesn’t matter if anyone pays attention.
All this to say I think this is all a little spicy but surely we all mean well. breathes deeply, let’s just do a little twist and get back to the fun :D.
Your README starts with “A git web frontend written in Go.” […] What does it tell me? I don’t know.
I don’t really see the problem with this. The link is to a demonstration of legit, using the repo of legit. Even before you read the README, you can see how it styles commits by default (at the top of the page), and you can click around to see how navigation is setup. Was the link changed after the story was posted?
I think it’s pretty useful information to have in the readme as it informs the user of what language tooling they’d need to build/run this
I’d like to thank you for writing this in your README. It’s often surprisingly hard to find, and often I come across tools that are written in multiple languages (not necessarily a bad thing) that I would use except that I don’t want downstream to have to have a JRE, Python, and Ruby installation all working (or, worse, specific versions of those things). I don’t really care that it’s Go, but I do care that Go defaults to spitting out a single statically linked binary and so building it is generally just go build and then end up with something redistributable.
I think you have misunderstand why I have made this comment.
’m now convinced you didn’t read beyond the first few lines
Yes I had only read the first few lines because I was drinking my morning coffee and left after that to work[0].
I think it’s pretty useful information to have in the readme
Yes it is useful information, but is this the information a potantial user wants/needs before spending more then 5 minutes to consider using your tool? It would be sad, if your tool is missed by many people just because you can’t convince them to read more then the title of your post or the first two paragraphs of the readme.
[0] I was already a bit late, because I had to help someone debug there TLS config ;-)
I think I just internalized the “foo, written in bar” format and wrote the headline like that.
Now that you know how annoying these type of headlines can be and since you too admit that such headlines are annoying, can you fix the title now (if you still have edit window)?
I am confident that you are turning away many potential readers due to this title. The moment I saw “Foo, written in bar” in the title, my brain automatically decided to avoid clicking your link. If you had a title like, “Foo, summary of why it is better” or “Foo, one key problem it solves well” I might have felt like clicking on it.
This started with the movement to rewrite everything in rust (“grep but in rust”, “cat but in rust”, etc.) which was fun at the time, but rewrite for the sake of rewrite got boring
These actually provide some useful information, for example there’s a big difference between reading “$server_side thing written in Python” (probably a giant mess to deploy!) vs. “$server_side thing written in Rust/Go” (probably an easy single-binary deploy!).
“Probably”. And that’s the problem. The OP can communicate much more information by simply stating that the whole thing is a single-binary deploy. Then I wouldn’t have to guess that “Go” => “probably an easy single-binary deploy!”
my mind is probably poisend by $POPULAR_GIT_HOSTING site, but the categories “tree, refs, log” always feel unnatural to me. I know they are the right terminology, just so rarely used.
Your webserver gives another cert on IPv6 then on IPv4. The cert on a IPv4 connection is valid for git.icyphox.sh the cert on IPv6 is only valid for h.icyphox.sh.
Ah okay, I see the problem. I had a stray <ipv6_addr>.crt file lying around in my /etc/ssl/ directory, and relayd was picking it up. Should be solved, I think.
Yes, this is currently only for read ops (cloning and pulling). While the ability to push over http exists, I’ve disabled it for now because it would require the additional
step of setting up authentication. I could perhaps make this configurable, and let the user figure out auth themselves, but I have no incentive to as I personally don’t need it. Patches welcome.
Hi, I did initially look at smithy, but my NIH kicked in and I decided to write one myself. I also don’t agree with certain choices of libraries etc. in smithy (like gin).
fwiw @icy I think some individuals are being a tad over the top with their responses… Good job with the tool :) Gets the job done.
I didn’t see a single comment that crossed the line on being hostile but before leaving feedback on a post like this I’d urge you all to weigh two things: (1) the importance your feedback be heard vs (2) that feedback contributing to an environment that would make a person not do such work again in the future (or at least not announce it on this site).
Usually negative, constructive feedback is good but I don’t see how anyone could read this comments section and declare it useful.
This, exactly.
Here’s someone who’s shared a hobbyist project they worked on for a week, and what’s the response like?
Like, if you wanted this place to become the orange site, well done all, you’ve done it! its now as obnoxious and as useful.
This is something I’ve been hacking on for the past week or so, born out of my frustration with cgit being terrible to use on mobile. The default styling is somewhat opinionated, so you might want to change it up. Also available on GitHub, if that’s your thing.
Let me know if you have any trouble setting it up—I’ll be happy to help.
Bookmarking.
What are your thoughts on using it to front
gitolite? That’s where I store my git repos, I like the user granularity, but I think I’d need to put an auth layer in front of this site to make it work right.Shame I can’t use an ssh key for web authentication! (cue lots of people telling me how?)
I’m not the author, but I’ve also experimented with a stand-alone ssh git service which keeps all its keys in git (similar to how gitolite does). I’d love to go back to that, clean it up, and add a web-ui somehow as well…
You could probably do auth by having someone sign a random string with their git private key… or provide a command they can use with ssh to get a login token.
Cool project! I ended up with gitolite specifically because it used the system sshd so I could also log in to the server as me. Made administration easier.
Interesting idea, signing something with ssh to generates a login token… that could have merit, and be easy for automation (vault I think could generate the token as it expires and replace it on servers needing the token to be fresh)
I’m not sure if it’s still a thing, but that’s similar to one of the “second factors” we allowed for 2fa account recovery at Bitbucket - you could SSH in (and run a specific command) and it would count that as a login. I think when they migrated to Atlassian ID, that went away though.
No idea if I’ll find the time to work on it soon, but it could be interesting! We’ll have to see where it falls in terms of my personal project prioritization.
Remember that an exciting part is granting specific keys specific access to specific repositories. It could be quite interesting.
There is also https://git.codemadness.org/stagit/
It’s fun to contrast the presentation of both these tools. While legit has a very calm, spacious layout (which I like), it’s not as immediate or easy to ready at a glance as stagit’s compressed, bare layout.
There is an esoteric programming language of the same name: https://blinry.org/legit/
Can we stop the $tool written in $language type of headlines? It’s annoying. Yes write tools in whatever language you like. But give some other argument why this implementation is better then the rest. Because a skilled programmer can write horrible code in any language ;-)
I’m sorry you’re miffed by the headline—I too feel similarly about “written in Rust” posts. I think I just internalized the “foo, written in bar” format and wrote the headline like that. As for why this is better, I’ve briefly outlined it in the readme.
I don’t find this info unnecessary and it actually helps me decide to checkout a project. I am familiar with Go, so any project in Go gets my attention quickly. If the title didn’t mention the language, then first thing I would do is to check which language it is written in.
It’s a self hosting tool. Language and the tooling matters a lot to me.
Languages that compile to a binary also tell me something about the performance characteristics I can expect. I don’t know (and am not curious about) Go, but I know it will more than likely produce something pretty quick and light on resources. The self-hosting part is real too because you should be assured that you won’t need high-end hardware like hosting a Rails server.
Personally, that it’s written in
gois more useful to me thanwritten in nodeorwritten in java. It tells me a lot about the “handling characteristics” of the program from an operations standpoint, and that’s valuable.Your readme starts with “A git web frontend written in Go” followed by a pronounce guide. Maybe try something like “A small, customizable git web frontend”.
FWIW, I am only interested in hacking on an OSS web app if it’s written in Go. As a developer I’m not really interested in ones written in other languages, although I will use them as a consumer. So for me “written in Go” is a useful bit of signal.
I think it’s pretty useful information to have in the readme as it informs the user of what language tooling they’d need to build/run this. I’m now convinced you didn’t read beyond the first few lines, or you’d have reached the “features” section which does briefly outline why this is better than the rest. In the context of this post alone, I’d even argue that there’s plenty to glean by simply using the site (since it’s also the software being discussed).
You are being given good feedback and your first instinct is to negate the feedback as fast as you can type out a response with your keyboard without taking a moment to reflect on it, compose yourself and evaluate the feedback on its own merits.
What’s worse is that you then go on to insinuate that the parent commenter did not even read beyond the first first few lines! How can you possibly know that? How can you be so convinced that someone else on the internet did not read your complete post? This is not how to run a successful project!
I did read your entire post and I find the parent comment to be 100% right! Your README starts with “A git web frontend written in Go.” Then the very next thing it explains is how to pronounce your project name!
And then your features list has these 4 things:
What does it tell me? I don’t know. It’s a web-based tool. I can customize the templates. Fine. But why does it make it better? All web-based tools these days have customizable templates, right? Cloning over https(s). Sure. But why does it make it better than alternatives? What are the alternatives?
“Less archaic HTML.” What does that even mean? You mean no
<table>for layout? Does it really need to be mentioned in a project created in 2022?“No CGI”? Why tell us what it is not when you can simply tell us what it is? Maybe you mean to say that the web-server is built-in into the project (by virtue of Go
net/httpor one of its wrappers)? Maybe you mean to say that we can deploy it as a single binary? If that is what you want to say, just say that!Sorry but I have to agree with the parent comment. If you communicate more directly what your project is and why we should care about it, you would capture my attention and some other folks too who you are turning away right now.
I would like to offer a counterpoint to these things:
Personally, I like the current README. I think the information it offers is relevant for people who are looking for an alternative git web frontend.
Changing the description to some canned generic description (“light, customizable web-based git frontend”) would make it worse, that describes basically every frontend that doesn’t have a corporate licensing scheme.
Changing the rest of the README to list things that are relevant for everyone, not just people who are already familiar, but dissatisfied with existing git web frontends would be pretty counterproductive: these are literally the people who are probably interested in legit. Of course the README is written for them.
No not all web based tools have customizable templates.
I think the author may be comparing their project against cgit’s featureset, which gives those points more context as to why they’re important to mention.
cgit is CGI based, has archaic HTML, and no customizable templates. It can clone over https and more though.
It’s clear then the README assumes the reader / user is familiar with other git frontends. If not then just ignore the project and move on or dive deeper…
Our attention really means nothing, it’s a hobbyist project. They’re just sharing something they think others will be interested in. Really doesn’t matter if anyone pays attention.
All this to say I think this is all a little spicy but surely we all mean well. breathes deeply, let’s just do a little twist and get back to the fun :D.
I don’t really see the problem with this. The link is to a demonstration of legit, using the repo of legit. Even before you read the README, you can see how it styles commits by default (at the top of the page), and you can click around to see how navigation is setup. Was the link changed after the story was posted?
I’d like to thank you for writing this in your README. It’s often surprisingly hard to find, and often I come across tools that are written in multiple languages (not necessarily a bad thing) that I would use except that I don’t want downstream to have to have a JRE, Python, and Ruby installation all working (or, worse, specific versions of those things). I don’t really care that it’s Go, but I do care that Go defaults to spitting out a single statically linked binary and so building it is generally just
go buildand then end up with something redistributable.I think you have misunderstand why I have made this comment.
Yes I had only read the first few lines because I was drinking my morning coffee and left after that to work[0].
Yes it is useful information, but is this the information a potantial user wants/needs before spending more then 5 minutes to consider using your tool? It would be sad, if your tool is missed by many people just because you can’t convince them to read more then the title of your post or the first two paragraphs of the readme.
[0] I was already a bit late, because I had to help someone debug there TLS config ;-)
Now that you know how annoying these type of headlines can be and since you too admit that such headlines are annoying, can you fix the title now (if you still have edit window)?
I am confident that you are turning away many potential readers due to this title. The moment I saw “Foo, written in bar” in the title, my brain automatically decided to avoid clicking your link. If you had a title like, “Foo, summary of why it is better” or “Foo, one key problem it solves well” I might have felt like clicking on it.
IMO this should be a site wide rule.
This started with the movement to rewrite everything in rust (“grep but in rust”, “cat but in rust”, etc.) which was fun at the time, but rewrite for the sake of rewrite got boring
These actually provide some useful information, for example there’s a big difference between reading “$server_side thing written in Python” (probably a giant mess to deploy!) vs. “$server_side thing written in Rust/Go” (probably an easy single-binary deploy!).
“Probably”. And that’s the problem. The OP can communicate much more information by simply stating that the whole thing is a single-binary deploy. Then I wouldn’t have to guess that “Go” => “probably an easy single-binary deploy!”
Amazing.
my mind is probably poisend by $POPULAR_GIT_HOSTING site, but the categories “tree, refs, log” always feel unnatural to me. I know they are the right terminology, just so rarely used.
getting a certificate error (cert doesn’t cover the subdomain), clicking through the warning works though
That’s weird. Firefox and curl both report that the cert is fine.
Your webserver gives another cert on IPv6 then on IPv4. The cert on a IPv4 connection is valid for git.icyphox.sh the cert on IPv6 is only valid for h.icyphox.sh.
Ah okay, I see the problem. I had a stray
<ipv6_addr>.crtfile lying around in my/etc/ssl/directory, and relayd was picking it up. Should be solved, I think.I get a cert only valid for h.icyphox.sh
I also get this warning on Firefox iOS
ninja edit: actually, it seems to be intermittent
What does
Oui, il est le git!is supposed to mean? I’m French and it irritates me 😂Nothing. And judging from this thread, being French isn’t a requirement to be irritated. :^)
Is it just for read operations, aka can you use it to commit?
Yes, this is currently only for read ops (cloning and pulling). While the ability to push over http exists, I’ve disabled it for now because it would require the additional step of setting up authentication. I could perhaps make this configurable, and let the user figure out auth themselves, but I have no incentive to as I personally don’t need it. Patches welcome.
I love the tool and UI, simple, nice and gets the job done.
absolutely sick. i’ll probably flip my self-hosted repo over to this. <3 ty for sharing.
Cool project! Thanks for sharing it
You could have just contributed to smithy instead.
Hi, I did initially look at smithy, but my NIH kicked in and I decided to write one myself. I also don’t agree with certain choices of libraries etc. in smithy (like gin).
I find this response to be insulting, and I’m not even the author/OP!
I mean, what’s the point of creating anything new when something similar to it already exists? (that’s sarcasm, by the way…)
It was meant in jest. Clearly, I did the same with smithy. :)