1. 71

    Here’s a script to migrate your repos to hg.sr.ht:

    https://hg.sr.ht/~sircmpwn/invertbucket

    1. 4

      I like competition in general. Sometime I love watching it happen, though. :)

      1. 6

        hey @SirCmpwn thanks a ton for that script. Just imported 19 repos (both git and hg) into sr.ht. Some of those repos were 9 years old. : )

        1. 3

          Great :)

        2.  

          I went ahead and got a subscription for Source Hut even if I may only use it as a mirror for now.

          I think diversity is good and would like to play more with it in the future :)

        1. 6

          The number of times I’d wished I had this feature on Travis.

          Instead you just end up blindly pushing changes to the branch in the hope that it works :P

            1. 3

              Only on Travis-ci.com (the paid version), and not Travis-ci.org (the free version).

              1. 4

                sr.ht is also a paid service, right?

                1. 4

                  It’s up to you whether to pay or run the exact same free software on your own infra.

                  1. 2

                    Is it easy to run on your own? That’s kind of cool. I may pay them anyway but still run it myself.

                    1. 8

                      https://man.sr.ht/installation.md

                      Reach out to the mailing list if you run into trouble :)

                      1. 1

                        Wow, cool! Thanks :)

                    2. 1

                      You can also run travis-ci.org on your own infra (I currently do this) but there isn’t a lot of info about it.

                  2. 3

                    The trick is that for public repos, you have to email support: https://docs.travis-ci.com/user/running-build-in-debug-mode/#enabling-debug-mode

                    1. 1

                      Weird… I guess that they’re trying to prevent wasted containers by adding manual process in the middle?

                      1. 2

                        It’s a security risk, especially for public repos.

                        1. 2

                          Eeeek, that’s rough. builds.sr.ht’s SSH access uses the SSH keys we already have on your account for git authentication et al.

                          1. 1

                            You get that from Github, too. But I also think it doesn’t help, because GH projects are liberal with adding people to orgs/repos and while they cam be grouped, there’s no way to assign structures roles. GH as an identity provider is mediocre at best.

                          2. 1

                            Like, in terms of things which they may do in the shells, DDoSing by creating too many, etc? They use your SSH key from GitHub to prevent others from SSHing in, right?

                            1. 4

                              They use your SSH key from GitHub to prevent others from SSHing in, right?

                              Not AFAIR. It gives a temporary login/password in the build log (which is public). And anyone who logs in can see the unencrypted secrets (e.g. API keys used for pushing to GitHub).

                              1. 1

                                oooooooh… yipes. Super dangerous. CircleCI uses SSH keys to improve on this.

                      2. 1

                        Aren’t they doing some funky reorganization to eliminate the split? I haven’t looked closely so I might be wrong.

                      3. 2

                        I guess I’ve just been too cheap to pay then ;)

                      4. 1

                        This feature is on Travis, but their new configuration API is so excruciatingly painful and lacking of reasonable documentation that it fails to help when it’s really needed.

                        1. 1

                          With Gitlab you can debug CI stages on your machine by starting a local Gitlab Runner.

                        1. 3

                          we keep the VM alive until you log out or until your normal build time limit has elapsed

                          Immediately on logout? There should be like a couple minute window after logout when you can log back in, because connections can drop, accidental Ctrl-D in the wrong window can happen, etc.

                          soon you’ll be just a few keystrokes away from an ARM or PowerPC shell, too

                          Let me guess, EC2 and IntegriCloud? :)

                          1. 14

                            Aye, I’ll improve upon this over time.

                            Regarding EC2 and IntegriCloud, no - sr.ht is run entirely on owned hardware in a private rack in a colocated datacenter. I don’t put your data in the hands of megacorps.

                            1. 2

                              I don’t put your data in the hands of megacorps.

                              I’m impressed.

                            2. 1

                              There should be like a couple minute window after logout when you can log back in, because connections can drop, accidental Ctrl-D in the wrong window can happen, etc.

                              Not just for this exact scenario, but you can use SSH Sockets for this purpose!

                              1. 1

                                I’ve had that enabled for years. Not sure how it would help when the TCP connection gets dropped because of network problems.

                              2. 1

                                accidental Ctrl-D in the wrong window can happen

                                Set IGNOREEOF and you can (mostly) avoid that problem.

                                1. 0

                                  You can always rebuild there, yeah?

                                1. 20

                                  Other than noting that this is basically just advertising for a new feature of sr.ht, it should probably be tagged release (since it’s a new feature) and not practices or virtualization (since it doesn’t really teach anything about virtualization).

                                  1. 4

                                    Sorry, I still don’t fully grok the tags on lobsters.

                                    1. 2

                                      No worries! Practice makes perfect. :)

                                  1. 2

                                    I really like this, I just can’t go to an email-based workflow. It’s not just that I find it difficult, but I’d never be able to convince everyone I collaborate with to do it. I think Drew said at some point that he would consider web-based code review, any updates on that?

                                    1. 2

                                      It’s a work in progress, but I still insist that people give it a fair shake, especially after writing resources like git-send-email.io to make it as painless as possible. Lately I also find it prudent to remind people that their development mail client needn’t be their only mail client.

                                    1. 3

                                      Drew DeVault does your comment from last year that you’re opposed to officially supporting Docker deployment of sourcehut stand? I have a homelab where I like to mess with stuff and sourcehut’s Mercurial support looks really nice, but the install steps are daunting. I assume it wouldn’t actually be too bad, but when compared to something like Gitea’s declarative deployment via Docker which took me 3 seconds to start playing with, I hesitate. Either way thanks for working on sourcehut!

                                      p.s. how do you @-mention a user on here?

                                      1. 11

                                        Yes, it stands. What also stands is the idea that if someone were to take on the role of building a third-party docker deployment for sourcehut, they would find the task reasonably easy to accomplish and I would be supportive of them, albeit insistent that it remain a third-party solution.

                                        Note, however, that deploying sourcehut on docker is itself not the matter discussed in the linked ticket. As for the subject of the ticket, I still have no desire to address this at this time.

                                        1. 1

                                          Reasonable stance! Perhaps I will attempt to tackle it some time (if no one else beats me to it).

                                          I actually don’t even understand that ticket but it came up in a google search result for “sourcehut docker.” GPU passthrough with Docker? So confused.

                                          1. 2

                                            It’s for the CI service.

                                        2. 3

                                          @altano you just type @ in front of the username and the markdown formatting does the rest

                                          1. 3

                                            how do you @-mention a user on here?

                                            You just prepend @ to the username: @altano

                                          1. 24

                                            With respect to email, don’t forget that pull requests were once intimidating too - as anyone who frequently works with onboarding new developers to its workflow can attest. To help make onboarding users with email easier, I wrote this tutorial:

                                            https://git-send-email.io

                                            I also wrote a rebase guide which applies to both workflows for making your changes more consistent and easier to review:

                                            https://git-rebase.io

                                            1. 26

                                              https://git-send-email.io

                                              That nicely outlines how to send patches, but I think people have far more difficulty receiving patches via email. Not everyone uses mutt, aerc, or runs a patchwork instance. Many mail clients, that people are otherwise generally fairly happy using, are just super not great at handling emailed patches. Emailed patches also generally don’t show a CI status that you can view ahead of time (I have heard of some, but I don’t ever remember seeing it firsthand in the wild).

                                              It’s great that it (an email patch workflow) works well with your workflows and tooling, but for some people it just… doesn’t work as well.

                                              1. 3

                                                I mean, those people who don’t have such a mail client are missing out. It’s like arguing that we should use SVN because not everyone has git installed, in my opinion. And testing your patches against SourceHut CI is pretty easy, before or after it’s sent.

                                                1. 26

                                                  I think one issue is that for most of us, sending and receiving patches is a very small part of what we do with email, so choosing a mail client on that basis doesn’t make sense.

                                                  1. 1

                                                    But we aren’t forced to use only one mail client. I use several depending on context / the task at hand.

                                                    1. 1

                                                      I am curious about your multiclient workflow. Do you use multiple addresses, or use filters and one shared address? Or just all the mail in all of them?

                                                      1. 3

                                                        Whether you use local maildir or imap, mail stores are designed for concurrent access. How many people check email on their phone and not their phone?

                                                        1. 1

                                                          Sure, but my question was specifically about their workflow with it.

                                                        2. 2

                                                          As it happens I do use multiple accounts for multiple “hats”, but that’s slightly orthogonal to multiple clients, which I use even for a single account. My daily driver is mutt; I use thunderbird for rare occasions when I need to see rendered html properly or perform a search (still haven’t got mairix or not much etc set up) and I often use ios mail app but mostly read only.

                                                          At work we use Gmail. I do check that from ios mail app too. I recently started configuring mutt to read my work mail too but it’s a work in progress so I still regularly open the Gmail website.

                                                    2. 23

                                                      I mean, those people who don’t have such a mail client are missing out. It’s like arguing that we should use SVN because not everyone has git installed, in my opinion.

                                                      To me it sounds a bit more like arguing “anyone who doesn’t ride a penny-farthing to work every day is totally missing out”.
                                                      Well…maybe.. I do find it unlikely that is going to convince very many people who weren’t already riding them, or weren’t already inclined to do so. Even if it is amazing.

                                                      Sidenote1: I may be wrong, but it even appears that Mutt itself uses gitlab instead of email based patches. If true, I find that oddly humorous.

                                                      Sidenote2: I have nothing against email based patch flows, and if I am going to contribute to a project, I generally contribute in whatever form a project requires (within reason). But for my own projects, I do not desire an emailed patches based workflow (EPBW), nor do I desire to run/manage/admin/moderate(remove spam) a mailing list. That’s just me though.

                                                      1. 6

                                                        To me it sounds a bit more like arguing “anyone who doesn’t ride a penny-farthing to work every day is totally missing out”.

                                                        I don’t really like this take. Having sunk thousands of hours into the GitHub, Gerrit, and email-driven workflows, I can confidently assert that the email-driven workflow, even setting aside the many respects in which it is politically and technically superior, is simply the most efficient for both contributors and maintainers. The penny farthing comparison is unfair.

                                                        Sidenote1: I may be wrong, but it even appears that Mutt itself uses gitlab instead of email based patches. If true, I find the humorous.

                                                        Mutt uses Gitlab and mailing lists and Sourcehut, actually. The dominant avenue of contributions to mutt is through its hosted mailing list. They use Sourcehut CI, however.

                                                        Sidenote2: I have nothing against email based patch flows, and if I am going to contribute to a project, I generally contribute in whatever form a project requires (within reason). But for my own projects, I do not desire an emailed patches based workflow (EPBW), nor do I desire to run/manage/admin/moderate(remove spam) a mailing list. That’s just me though.

                                                        That’s why Sourcehut can do it for you.

                                                        1. 9

                                                          I don’t really like this take. Having sunk thousands of hours into the GitHub, Gerrit, and email-driven workflows, I can confidently assert that the email-driven workflow, even setting aside the many respects in which it is politically and technically superior, is simply the most efficient for both contributors and maintainers. The penny farthing comparison is unfair.

                                                          A bit of an “Ipse dixit”, but I’ll take it at face value anyway. To be clear, my comment was in response to your statement:

                                                          I mean, those people who don’t have such a mail client are missing out.

                                                          Which is what I made the comparison against. You have now pulled in other concerns in your response, and attributed them to the comment I made. I find that a bit uncharitable. I guess at this point we can just agree to disagree.

                                                          Mutt uses Gitlab and mailing lists and Sourcehut, actually. The dominant avenue of contributions to mutt is through its hosted mailing list. They use Sourcehut CI, however.

                                                          That’s odd. I looked through the last 2 months of their mutt-dev mailing list, and saw no mailed patches, but several gitlab PRs. Maybe I saw the wrong mailing list? Maybe I didn’t go back far enough? Overlooked it?
                                                          It doesn’t really matter, and I’ll take your word for it that they predominantly use emailed patches.

                                                          1. 1

                                                            The last 2 months have only seen one patch on Gitlab:

                                                            https://gitlab.com/muttmua/mutt/merge_requests?scope=all&utf8=%E2%9C%93&state=merged

                                                            After reviewing it myself I have to correct myself, I reckon that Gitlab and the mailing lists are at about an even pace these days.

                                                            1. 2

                                                              Do note: that was merged PRs. There were a couple of more (not many though!) in All which is what I looked at.

                                                      2. 5

                                                        Not everyone is productive using such mail client. Personally, I just plainly cannot remember more than a few shortcuts, which is already a massive roadblock for effectively using CLI tools as for most of them rely on shortcuts to increase productivity, they also do not provide me with options of what I can do, and I cannot for my life remember what can I do for all the possible contexts, cause of course options on what you can do are dependent on the context which you are currently in. Some people just aren’t productive using CLI tools, and saying that they “are missing out” because they plainly cannot effectively use the tool is simply gatekeeping.

                                                        1. 2

                                                          saying that they “are missing out” because they plainly cannot effectively use the tool is simply gatekeeping.

                                                          This is absurd. If a mechanic decides that he “is not a ratchet person” and will only ever use open-end wrenches, then I will question his professionalism just as I would question a software developer that “is not a CLI person” and will not learn to use a CLI mail client.

                                                          He doesn’t need to use the CLI mail client for his day-to-day email, but he should be capable of learning how to use it to handle the occasional emailed patches.

                                                          1. 5

                                                            Or this person will work with whatever, when paid for (professionals are paid for their work by definition!), but will only work with tools he/she finds enjoyable when doing charity. Thus FLOSS projects forcing inconvenient, last century methods with arrogant communication are missing contribution.

                                                            I thing the FLOSS community should focus on this kind of openness more, instead of CoCs.

                                                            1. 2

                                                              Good point. For work I’ll use whatever tools get the job done, no matter how gruesome. But for FOSS contributions, I agree that if the tool is difficult or simply frustrating to use, then it may as well not exist.

                                                            2. 1

                                                              Wrong assumption. Difference between using GUI and CLI clients is not like between open-end and ratcheted wrenches. Using those wrenches is basically the same. Meanwhile the experience between using CLI and GUI mail client is a lot bigger. I’d compare it to using automatic and manual wood planes. You can work with higher precision and similar speed with manual hand plane, but most carpenters would choose automatic hand plane, as it “just works” and doesn’t require that much skill and learning to do.

                                                              And why should you care what kind of wrench does your car mechanic uses, if he does the job well? This isn’t a problem not using better tools, but a problem of tool abilities. The tools that an average developer uses does not represent the tools that are created for that workflow. And that is a problem.

                                                              1. 1

                                                                I’ll entertain the analogy to a wood plane, though I’m unfamiliar with the devices. You say it yourself: the manual wood plane is useful in certain circumstances but requires skill. So does the CLI mail client. Use the automatic wood plane where it fits, but at least learn the skill to use the manual wood plane where the higher precision is necessary.

                                                                A developer that refuses to acquire a skill is simply not professional.

                                                                1. 1

                                                                  It’s not like it requires much skill. It is the basically the same skill. The difference is, you need to move the manual wood plane along the plank 10 times, while with automatic you only need to move it once and the motor does its job. Some people just don’t have the patience and/or physical stamina to use manual wood plane. Manual hand plane is in fact more configurable, and can be used in more specialized scenarios. So enthusiasts use hand planes. Your average carpenter does not.

                                                                  1. 1

                                                                    The analogy was not mine.

                                                            3. -1

                                                              Consider acme?

                                                              1. 2

                                                                I am unable to find such email client. And the point is, for a workflow to be usable by a wide range of people, it should require as little new tools that do the same as the ones they use. And in case of email clients, most people probably like their current email client, and they do not want to change it. So they, in turn, do not want to switch to this new workflow, which, while potentially increases productivity, requires them to switch to tools they do not like.

                                                                1. 3

                                                                  acme is a text editor which can be easily coaxed into being a mail client.

                                                                  Consider as well that you needn’t discard your daily mail client in order to adopt another. What difference does it make if some technology is backed by email or by some other protocol? Just because you already have an HTTP client (e.g. your web browser) doesn’t mean another isn’t useful (e.g. curl).

                                                                  1. 7

                                                                    Acme does not seem like general user friendly. My colleagues all use JetBrains IDE’s and use Thunderbird as their mail client. And acme would be a downgrade for their experience. I might use it, but they wouldn’t. If I cannot offer them a good GUI email interface, there is no way they would switch to email-based workflow.

                                                                    1. -1

                                                                      I was recommending acme particularly for you, given the following:

                                                                      I just plainly cannot remember more than a few shortcuts

                                                                      If your colleagues won’t join you I consider your colleagues to be in the wrong, not the software. A bicycle is easier to use than a car but it’s not going to get you to the other end of town in time for the movie.

                                                                      1. 14

                                                                        If your colleagues won’t join you I consider your colleagues to be in the wrong, not the software.

                                                                        Don’t you think peace within a team is more important than any particular software or workflow? Or, to put it another way, the feelings of people are more important than any workflow, so if a large group of people reject a workflow, it’s better to conclude that the workflow is wrong for those people than to say that those people are wrong.

                                                                        1. 7

                                                                          My colleagues wouldn’t join me because the workflow is bad, but because there is no tooling suitable for them and the workflow. If tooling for a specific workflow just isn’t comfortable for me, I’m just not going to use it.

                                                                          1. -9

                                                                            Then you ought to be coding in basic. Good things often require effort.

                                                                            Edit: this comment seems to be being misinterpreted, so a clarification: I’m not earnestly suggesting that he should use basic. I’m extending his logic to an incorrect conclusion to demonstrate the flaw in his argument. Most languages are harder than Basic, therefore Basic is more comfortable, therefore why ever learn anything else? Obviously it doesn’t make sense.

                                                                            1. 18

                                                                              You are literally making the exact same argument that @ignaloidas’ colleagues are. The only difference is that the tooling you find suitable and the tooling they find suitable is a null set. They want to be in JetBrains’ IDEs, you want to be in email. You built tooling that demands email-based workflow because it’s what you want and then tell them they have to change; they’ve got tooling that demands GitHub (or a workalike) and then tell their colleagues that they have to change.

                                                                              As an aside, I pay for and generally enjoy using Sourcehut, and I respect your diehard allegiance to email, but you’ve got to quit acting like this in the threads. I get that you love an email-based workflow, and find it superior for your use cases. Having used Git and Mercurial since, what, early 2006 I guess—certainly before GitHub and Bitbucket existed—I disagree (especially when your workflow starts to involve binary assets, so most websites, games, mobile apps, and so on), but I’m also comfy in that workflow, and happy to support an SCM that fully supports that flow. But if you insist that people who do not use your workflow are wrong, and do so in this offensive manner, you’re going to start losing customers.

                                                                              And as an aside to that aside, you need to do what you want with Sourcehut, but the fighting against this on principles to me, as a former SCM lead, looks a bit forced: looking at this whole thread, and thinking back to a very early comment, all you’d have to do to satisfy him is to make temporary branch names that can be pulled in some mechanism based on the patch series. That’s it. It’s not trivial, but it’s also not that difficult, since you’re already doing 90% of that with the patch view. If you don’t want to do it, that’s fine, but it seems like that’d still mandate patch-accessible workflows, while also meeting the PR crowd a bit.

                                                                              1. 2

                                                                                Note about the JetBrains’ IDEs. It’s not like they are incompatible with with email driven workflow, they just have tools that are better suited for pull-request workflow. I gave JetBrains IDEs as an example of what an “average” developer as I know it uses from day to day, as it seems that many bloggers have a distorted view of “average” developer. Average developer actually doesn’t want to fiddle with settings and try 10 different variants before deciding to use one. They want tools that “just work” without massive setup. Average carpenter wants a table saw that simply does the job they want to, they do not fiddle around it to make it the best saw for them.

                                                                              2. 14

                                                                                Hi this is not a very nice tone, please try to argue in good faith.

                                                                                1. 13

                                                                                  Is insulting prospective customers really the best way to grow your business?

                                                                                  1. -1

                                                                                    That was no insult, it was a logical extension of his logic. I didn’t mean it sincerely, I was using it to explain his error.

                                                                                  2. 2

                                                                                    Ok, in simpler terms. I would probably still use an SUV instead of Smart even if Smart can go through some shorter paths, because I feel cramped when driving it. Same with software. Some software is in fact more useful than other, but is harder/inconvenient to use for some than software which doesn’t have those fancy features.

                                                                                    1. -6

                                                                                      This isn’t such a case. This is a case where you (or your colleagues, I’m not sure at this point) are refusing to try unfamiliar things and, being ignorant of the experience, asserting it’s worse.

                                                                                      1. 3

                                                                                        It is. The thing is, I have tried mutt and aerc, and the problem is that I just plainly am not comfortable using bigger CLI programs, that is, those, whose scope goes out of pipes and command line rguments. About the only programs that of such style that I can use is nano and htop, only because they have a handy shortcut guide in the bottom at all times. Acme is also not the kind of editor I would like to use casually. It is easy to blame the people that don’t use it, without understanding the reasons why they don’t use it.

                                                                                        1. -1

                                                                                          You didn’t know anything of acme not even 2 hours ago. You’ve evaluated it in that time?

                                                                                          Herein lies my point. I have a vision and I must at some point exercise my creative authority over the project to secure that vision. Yes, it’s different from what you’re used to. You can construct reasons to excuse this away, but I fundamentally believe that being unwilling to learn something new is the underlying problem. As evidence, I submit that there’s no way you could have given acme a fair evaluation since my suggestion of it. I don’t consider this sort of behavior acceptable cause for changing my system’s design to accomodate.

                                                                                          1. 12

                                                                                            As someone who used Acme for two years, @ignaloidas does not sound like someone for whom Acme would even be worth trying. It’s great, but incredibly dependent on how you want to use your editor. You can’t disable word wrap, or use any shortcut to move the cursor down a column, for Christ’s sake. It’s really not for everybody (perhaps not even most people).

                                                                          2. 1

                                                                            So they, in turn, do not want to switch to this new workflow, which, while potentially increases productivity, requires them to switch to tools they do not like.

                                                                            What happened to using the right tool for the job?

                                                                            1. 1

                                                                              The question here is not about “the right tool for the job” but about the usability of those tools for the wider audience. Currently I do not see the majority of the developers switching to email-based workflow purely because of the usability of tools. “Rockstar developers” think that CLI’s are very usable and productive, but that is not the case for the average programmer.

                                                                              1. 2

                                                                                “Rockstar developers” think that CLI’s are very usable and productive, but that is not the case for the average programmer.

                                                                                Good to know that we were all rockstars for decades without realizing it!

                                                                                This is probably just an age thing but I don’t know any professional programmers who aren’t comfortable with CLIs.

                                                                                1. 3

                                                                                  There is CLI, and there is CLI application. Git is used through CLI. Vim is a CLI application. Surely you know at least one professional programmer that isn’t comfortable with Vim and alike.

                                                                      2. 3

                                                                        I am not particularly experienced at using git with email. One problem I have had in the past is when I want to pull in a patchset from a mailinglist archive, where either I am not subscribed to the mailinglist, or wasn’t subscribed at the time when the patches were sent. Can these mail clients help me with this problem? (By contrast, I find it very easy to add a branch / PR as a remote and pull or cherry-pick commits that way)

                                                                        1. 2

                                                                          lists.sr.ht, the sourcehut web archive for mailing lists, has a little copy+paste command line thing you can use to import any patch (or patchset) into your local git repo. Here’s an example:

                                                                          https://lists.sr.ht/~sircmpwn/aerc/patches/7471

                                                                          On the right, expand the “how do I use this” box and a short command is given there.

                                                                          Integration directly with your mail client would require more development but isn’t necessarily out of the question.

                                                                          1. 3

                                                                            That’s good to see, but presumably doesn’t help for non-sourcehut mailinglists?

                                                                            1. 2

                                                                              No, I’m afraid that there are fewer good solutions for non-sourcehut mailing lists. Patchworks has a similar feature, if the list in question has that set up. You could also ask someone else for a copy of the mail. I don’t think this damns the idea, it just shows that we need better software to support the idea - which is what sourcehut tries to be.

                                                                    2. 2

                                                                      I am still trying to find some time to check out Sourcehut. My only concern is how to configure it to run CI builds on mailing list patches as I couldn’t find it anywhere in the docs.

                                                                      1. 1

                                                                        This hasn’t been implemented yet, but it will be soon.

                                                                        1. 1

                                                                          Great. If that happens I will think about migrating some of my personal projects to the Sourcehut as it seems pretty as a pretty nice solution.

                                                                    1. 8

                                                                      Great ideas, but doomed to suffer forever living in an obscure github project far outside of the mainstream. I wish more people would consider contributing to upstream git - it’s open source!

                                                                      1. 22

                                                                        This is called “top posting” and is strongly discouraged.

                                                                        This recommendation should be tempered by the golden rule of email of etiquette, which is pick a format and stick with it. The only style worse than top posting is when half of the people on a list are top posting and the other half are posting inline. This makes finding relevant information a massive pain and can confuse some email clients drastically. If the culture of your email list is to top post, then bite the bullet and do it, because trying to be the renegade will only lead to greater confusion.

                                                                        That being said, if you’re the first to reply or setting a new precedent, then take this as a great and powerful opportunity to make a community of better netizens.

                                                                        1. 3

                                                                          While I agree with what you wrote, I don’t get why bottom posting is encouraged? That ways the receiver first sees the quoted text, and only after scrolling down gets to read the actual content.

                                                                          1. 11

                                                                            Does this answer your question? :)

                                                                            While I agree with what you wrote, I don’t get why bottom posting is encouraged? That ways the receiver first sees the quoted text, and only after scrolling down gets to read the actual content.

                                                                            This recommendation should be tempered by the golden rule of email of etiquette, which is pick a format and stick with it. The only style worse than top posting is when half of the people on a list are top posting and the other half are posting inline. This makes finding relevant information a massive pain and can confuse some email clients drastically. If the culture of your email list is to top post, then bite the bullet and do it, because trying to be the renegade will only lead to greater confusion.

                                                                            That being said, if you’re the first to reply or setting a new precedent, then take this as a great and powerful opportunity to make a community of better netizens.

                                                                            This is called “top posting” and is strongly discouraged.

                                                                            Seriously though, I think it’s odd that people use bottom posting in forums like this one fluently, but find it so difficult in emails. I’m inclined to blame bad default behaviour of certain clients.

                                                                            1. 6

                                                                              Bottom posting isn’t to be used indescriminately. You should delete any text from the original message which isn’t directly relevant to what you have to say, and interleave short quotes with short responses underneath. You can also just remove the original quote entirely if it’s not necessary.

                                                                              1. 4

                                                                                Thing is, it’s just too much of a hassle for most people which is why we ended up with top posting.

                                                                                1. 3

                                                                                  OK, that I also agree with. But how is that related to top/bottom posting? Seems like the thing to encourage here is selective quotes, not top/bottom posting.

                                                                                  1. 4

                                                                                    Bottom posting is not the opposite of top posting, despite what the name implies. The “selective quoting” style is generally known as bottom posting.

                                                                                    1. 3

                                                                                      Interesting, thanks for clearing that up.

                                                                                      Bottom posting is not the opposite of top posting, despite what the name implies.

                                                                                      This somehow reminds me of naming things. ¯_(ツ)_/¯

                                                                                      1. 3

                                                                                        Here’s your missing arm back: ¯\_(ツ)_/¯

                                                                                        1. 2

                                                                                          Maybe useful: https://shru.gg/r

                                                                                          1. 2

                                                                                            Thanks for the tip! Easy to break though: “¯\_(ツ)/¯ wait, why is this italic? oh, that’s better… but now my other arm is missing :/”

                                                                                            1. 1

                                                                                              Oh hold on, do you mean that paste doesn’t work on Lobsters?

                                                                                              1. 2

                                                                                                No, you just need an extra backslash: ¯\\\_(ツ)\_/¯

                                                                                                1. 2

                                                                                                  Aha, okay, I’ll add that in. Thanks! Should be fixed in ~60s.

                                                                                                  1. 2

                                                                                                    Oh wow! Nice, thanks.

                                                                                      2. 3

                                                                                        That’s not my experience. At least in the communities I’ve participated in, bottom-posting describes the practise of not trimming the quoted mail at all, and is frowned upon.

                                                                                        1. 1

                                                                                          Interesting that this understanding varies. Might I ask which communities you’re referring to?

                                                                                          1. 2

                                                                                            In particular I think that’s the excepted interpretation in the Debian community. But from what I remember it was generally so on usenet too.

                                                                              1. 2

                                                                                If I’m recalling correctly, I think that the author is incorrect about Apple Mail not wrapping automatically. It was my understanding that it breaks long lines (for plaintext only) during the sending process.

                                                                                Otherwise, good post. I support 👍.

                                                                                1. 4

                                                                                  Can you send me an email with long lines to sir@cmpwn.com so I can re-evaluate it?

                                                                                  1. 2

                                                                                    Will have to wait until I get home, but I’m very curious to find out so I will definitely sent you one ASAP.

                                                                                  2. 2

                                                                                    Apple Mail user here. Mail.app doesn’t automatically wrap, but there’s a plugin, MailFlow, that does it: https://github.com/arachsys/mailflow

                                                                                    There’s also MailWrap, which provides slightly different features from MailFlow: https://github.com/arachsys/mailwrap

                                                                                    1. 1

                                                                                      Thanks for debunking my bad information! My apologies to the author.

                                                                                  1. 4

                                                                                    An aside: The SVG is quite big and didn’t load directly, maybe compress it using https://github.com/svg/svgo

                                                                                    1. 4

                                                                                      It’s pretty small actually, file size and image dimensions both. Are you doing something odd with your web browser?

                                                                                      1. 5

                                                                                        Loading it was noticeably slow on my end, too, and I wouldn’t call 171 kB pretty small - not when a PNG version at the same resolution is ~14 kB, as converted by ImageMagick.

                                                                                        1. 4

                                                                                          You’re right, I ran it through svgo and got it down to 80K.

                                                                                    1. 10

                                                                                      I did some tinkering yesterday on an implementation of this for Rust code. I doesn’t work yet but I did set up the JSON generation and source parsing. The next step is to traverse the AST and generate the actual annotations.

                                                                                      https://git.sr.ht/~wezm/annotate-rust

                                                                                      1. 3

                                                                                        Nice! Looking forward to seeing the full implementation.

                                                                                      1. 1

                                                                                        are they offering HTTPS yet - i would like to move away from GitHub if possible

                                                                                        1. 11

                                                                                          …SourceHut has had HTTPS for all services since day one.

                                                                                          1. 2

                                                                                            push and pull?

                                                                                            1. 8

                                                                                              Oh, no. We support git pull over https, but not push, because SSH is the more secure of the two options. This is a deliberate design decision, not an oversight.

                                                                                              1. 1

                                                                                                are you willing to lose users by not having HTTPS support? cause thats what is happening in my case

                                                                                                HTTPS might be less secure, but it does does offer some security.

                                                                                                do you have some underlying reason for being obstinate about this? is it cost?

                                                                                                1. 9

                                                                                                  @SirCmpwn is famously stubborn about these things. See also discussions about styling and why if your monitor is the wrong size (e.g., normal) everything is awkwardly left-justified.

                                                                                                  For what it’s worth, that stubbornness is likely also going to result in a refusal to compromise on the more important technical issues that could hurt security or performance.

                                                                                                  Edit: also, to somewhat voice support for the SSH point of view–being able to revoke authentication on a per-host basis (or possibly to improve automation) is really quite handy. The alternative for scripting with https upstreams is putting the credentials in the URL (which is gross and stored in plaintext), or other hashing that eventually makes you just wish you’d used ssh in the first place.

                                                                                                  If it helps, I can send you the private key and passphrase part of this one (generated with ssh-keygen -b 4096 -t rsa -C noname -f throwaway):

                                                                                                  ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDMR82IOcor4hdiyeBIDQC/x0ubPVrVFw3zuPLvtXBQQsqD7znRHSsJAlNLD9iPtUdxjj2HjyLLfHrNAa0/iXPQStL5ErtK5+UqVq4seQCoyuakZoWGhmDKb3UAphiwLBuNQYdr/cJ7gLHNxN06thpEbx9pRG4jex1vb8DUfjgDdD5IEb859/pSoY5CTjni4Z+ZKllaCfrQgHNy/tYowxzjNa1HjJnR1SwqDNPrGgF4tJK+zXE4zbQcL3winIrNnvuBzGQmt36x6B6mQSEH32k/L8BAKAegP3CK8DZn9G0pi53Gj9arGYdY23jAT6fUeuAN87iggNo6NT0+jILMFt2rdPMiZj3KnVGcMdQEEqlX9sCw1jTe6v+n8d9wf2VFz45mU3ThrSmzSkyUNvhRV7RwJ6vRVgJ7LuOLZu1PByFMnVG5t5Hc8enS7MrD3bJNHn0q7lX5MBYFBSGbdozu7kY/Pyj/mxd3RNxEoXNmQ7JcolZiDxqGkRaanLDGEBzyLCitJAat30VkBnI/VKSN9jrmygNkg0LTKHY8rxtKZVHmUlDQF6Xuj4O9X7kJ2Xc/ov+dGl0ad38jH0bRtEtoKsGhY53Nw7d43bpOkh7Nhv40KaJVB4XUP23aGgkUDrdoVHyyxu3tqk+8dr1+YdrtwG3gUN8iliu6kSEzwlvhNMN89w== noname
                                                                                                  
                                                                                                  1. 14

                                                                                                    It’s not about cost. It’s about choosing the right tools for the job. HTTP Basic auth is the wrong tool for this job. I don’t want you transmitting your password over the wire, git.sr.ht doesn’t even know your password (or its hash). Why is SSH such a showstopper for you?

                                                                                                    1. 4

                                                                                                      Why is SSH such a showstopper for you?

                                                                                                      Not the OP, but my company doesn’t allow SSH out of the enterprise (I work in government where the company is several thousand employees). Thus anything that doesn’t offer HTTPS push is a no-go. I know of several other companies off the top of my head with similar restrictions.

                                                                                                      1. 1

                                                                                                        I remember how much I hated SSH when I first started by using GitHub 8 years ago. It’s an unnecessary complication. If users want the extra security SSH is available, but it shouldn’t be the only option.

                                                                                                        1. 27

                                                                                                          Sorry, SourceHut is probably not for you.

                                                                                                          1. 20

                                                                                                            A couple of thoughts from me in my capacity as the founder and (very much former) lead dev on Kiln, another Git/Mercurial SCM from around the same time GitHub launched.

                                                                                                            First, I’m really with @SirCmpwn on this. Kiln supported pushing and pulling over HTTPS, but only because we targeted Windows users—and even then, only because Windows SSH clients were really rough at the time. If I were writing Kiln today, I really doubt I’d add HTTP push support. I might’ve added support for it eventually anyway in that parallel universe, who knows, but I definitely wouldn’t have kicked off with HTTPS push at launch.

                                                                                                            Which brings me to:

                                                                                                            I remember how much I hated SSH when I first started by using GitHub 8 years ago.

                                                                                                            I really appreciate that SSH can be tricky, but I’m disappointed you’d let an impression you had in 2011 unilaterally cause you to reject the tool in 2019, regardless of what platform you’re on. TortoiseHg, Tower, Git for Windows, SourceTree, and tons of other tools have made handling SSH straightforward. It may still be too complicated for your comfort, but I’d be really hesitant to judge any technology on how it was eight years ago.

                                                                                                            I’m also genuinely a bit surprised that you’d be willing to move your entire workflow from GitHub/GitLab/etc. to Sourcehut, but the idea of configuring SSH would be your dealbreaker. Moving CIs, reconfiguring users, porting bugs, moving mailing lists, etc., is all more time consuming and more error-prone than configuring SSH.

                                                                                                            1. -2

                                                                                                              I’m also genuinely a bit surprised that you’d be willing to move your entire workflow from GitHub/GitLab/etc. to Sourcehut, but the idea of configuring SSH would be your dealbreaker.

                                                                                                              Good point, but my workflow is currently “low impact”, so it would be an easy move:

                                                                                                              Moving CIs,

                                                                                                              dont use them currently

                                                                                                              reconfiguring users,

                                                                                                              just me currently

                                                                                                              porting bugs,

                                                                                                              yeah that would be annoying - but my top 4 repos have a total of 17 issues, so nothing earth shattering.

                                                                                                              moving mailing lists, etc.,

                                                                                                              dont use those, for smaller projects its just redundant to github issues.

                                                                                                              is all more time consuming and more error-prone than configuring SSH.

                                                                                                              so you can see in my case if i could just find a decent site without the github feature bloat i would be happy to move. but currently sourcehut it not that option. yes SSH is more secure. but you know what? i dont care. maybe HTTPS will bite me someday and i will get hacked. but in 8 years it hasnt happened so i am happy to continue playing the odds. i am not happy with a site owner that refuses HTTPS not because of money, but because of some righteous insistence that SSH is the one and only way that is acceptable.

                                                                                                              1. 4

                                                                                                                yes SSH is more secure. but you know what? i dont care.

                                                                                                                So, fine, this is your life… but also you should be aware that your practice isn’t common practice, and it’s worse than the common practice of using ssh keys in almost every way. You should expect to encounter more resistance to your approach over time.

                                                                                                                Like, you can write your Windows 10 GUI software with php-gtk, but you’d be part of a rapidly diminishing minority. You’re right that you can’t use it to add things to the task tray, but if that’s what you want to do you’ll be far better served using a different, more popular toolset.

                                                                                                            2. 1

                                                                                                              I really don’t understand what there is to hate about it. As a user experience, it’s not much different one way or the other, aside from the initial setup.

                                                                                                          2. 1

                                                                                                            are you willing to lose users by not having HTTPS support? cause thats what is happening in my case

                                                                                                            I don’t understand. What do you need that for?

                                                                                                          3. -1

                                                                                                            Something like randomly generated repository specific https passwords may be interesting. Though even that is probably also just be a less secure complication.

                                                                                                    1. 7

                                                                                                      This looks very nice and polished!

                                                                                                      I wonder what’s the author’s opinion on Language Server Protocol that seems to solve a similar problem (but for IDEs) and git-appraise that also has schema for automated tools to add annotations (such as build statuses or lints).

                                                                                                      1. 4

                                                                                                        The LSP is pretty cool, and I wonder if an annotator could be made which leverages it. I think git-appraise does something a bit different, though (patch review).

                                                                                                      1. 3

                                                                                                        Am I misconceiving the feature? Isn’t it a problem that the annotations specify line numbers, because they can get out of sync as the code changes?

                                                                                                        1. 12

                                                                                                          Annotations are tied to the blob’s SHA.

                                                                                                          1. 3

                                                                                                            The annotations are also generated freshly by the continous integration system after each commit, so the line numbers will always be up-to-date.

                                                                                                          1. 2

                                                                                                            Does anyone know the CLI IRC client pictured there?

                                                                                                            Thanks in advance!

                                                                                                            1. 5

                                                                                                              Weechat.

                                                                                                            1. 4

                                                                                                              Agreed with everything here. I also put some patches in for a sr.ht project, and I didn’t have the same trouble as you did, but it was a fiddle to get it all to work out right. It’s not a big deal, except EVERY vcs hosted project has their own rules around how patches are accepted, and they all vary just enough that it’s generally a 10-60 minute pain EVERY TIME you want to do it, unless you are a regular contributor.

                                                                                                              This is why I think it would be great for a webpage form that accepts universal diffs & patches also be supported for sourcehut(sr.ht) and other VCS websites(github, gitlab, fossil, etc). I’ve never seen any of them support this however.

                                                                                                              Part of my job is evaluating new tech , so I’m always playing with X or Y, and when I find issues I used to work at sending patches, but now it’s generally a PITA, so at best I file an issue, depending on how much pain even that takes. If it’s not easy to contribute, it’s not remotely surprising that few do it.

                                                                                                              1. 5

                                                                                                                Sad this is a problem, glad that I get to hear about it. One thing to note is that setting up git-send-email once will generally get you 90% of the way there for most projects which accept email, though it can definitely be daunting upfront (I wrote a guide which helps a bit, feedback strongly desired).

                                                                                                                Another thing I want to do to help solve this is to show extra messages on git clone that succinctly describe what you need to do to upstream your work - things like automatically setting sendemail.to, format.subjectPrefix, and printing a short summary to your console when git clone completes.

                                                                                                                1. 3

                                                                                                                  Another thing I want to do to help solve this is to show extra messages on git clone that succinctly describe what you need to do to upstream your work - things like automatically setting sendemail.to, format.subjectPrefix, and printing a short summary to your console when git clone completes.

                                                                                                                  That would be very cool! I usually put this kind of info in README.

                                                                                                                  Do you have a relevant Message-ID or link to git mailing list discussion about this subject?

                                                                                                                  1. 3

                                                                                                                    I haven’t pitched it to the git ML yet because I haven’t solved all of the unknowns I know of myself yet.

                                                                                                                    1. 2

                                                                                                                      As far as I remember git will print remote output (GitHub/Gitlab use it when pushing to feature branches to print info on how to open PR/MR). Maybe the same thing can be reused for printing instructions on initial clone…

                                                                                                                  2. 3

                                                                                                                    I agree you are working on making git send email more user-friendly, and I think that’s great. But there will still be cases where people run into trouble(s). It doesn’t help that the git send email upstream code is perl, so even “binaries” for a given platform may not work out of the box. It also makes it impossible for people from tablets & phones to make contributions (git clients exist, but none of them support send-email that I’m aware of).

                                                                                                                    I’m not saying it’s your problem to solve and I want to thank you for your work to make git send email more friendly.. something the git team could have taken on themselves, but haven’t for whatever reason.

                                                                                                                    sourcehut, like github, etc support exactly 1 way to accept patches, and every system is different. I think this is bad and leads to less contributions overall.

                                                                                                                    I think allowing git to auto-set some per-repo settings for patches is a good idea.

                                                                                                                    I think about my teenage son, who can barely open a command line. He uses some open source software and has found some issues, but getting him set up to send documentation fix patches is generally way more trouble than he is willing to go through. Getting him to use git send-email is a non-starter. Now he is a young teenage boy, so maybe his documentation fixes would be too full of fart jokes to be actually useful.. ;P But if it was easy to contribute, maybe in a few years his contributions would actually be useful. But today as it stands, there is basically zero chance that will ever happen.

                                                                                                                    1. 1

                                                                                                                      In my opinion, it’s more appropriate to teach people about the right tools than to spend time catering to iPad programmers.

                                                                                                                1. 6

                                                                                                                  Nice article! Sorry to hear you found this to be a struggle. My key takeaways are:

                                                                                                                  1. openring’s readme doesn’t actually tell you how to contribute [fixed]
                                                                                                                  2. The page you land on when you finish registration should have a more obvious “how to contribute to projects on sourcehut” link. [fixed] Out of curiosity, did you click through the tutorials link? The tutorial that would have saved you isn’t there, but I’d like to know if it would have helped if it were.
                                                                                                                  3. There should probably be a troubleshooting page for when you run into issues like these with git-send-email (this isn’t normal)
                                                                                                                  1. 6

                                                                                                                    The page you land on when you finish registration (…)

                                                                                                                    As far as I understand sourcehut one doesn’t need an account to contribute. Maybe it would be beneficial to advertise it? (something like “you don’t need to register, just send e-mail to xyz”).

                                                                                                                    1. 4

                                                                                                                      Hm, good point. I’ll work on that.

                                                                                                                    2. 2

                                                                                                                      openring’s readme doesn’t actually tell you how to contribute [fixed]

                                                                                                                      Looks good!

                                                                                                                      did you click through the tutorials link?

                                                                                                                      I didn’t see one. I think I clicked on man and didn’t see anything relevant, and then gave up and decided to email a patch.

                                                                                                                      a troubleshooting page for when you run into issues like these with git-send-email

                                                                                                                      Part of why I wrote the blog post was so my error messages would show up to other people searching ;)

                                                                                                                      One thing I didn’t end up putting in the post was that there was actually another round of silliness: after I installed Net::SMTP::SSL and IO::Socket::SSL I didn’t notice that the error message I was getting had changed (I was getting sleepy) and I spent a while trying to figure out why they hadn’t installed properly (I thought maybe I’d selected the wrong value for local-vs-global?) Eventually I realized the error message was different and continued on.

                                                                                                                      1. 2

                                                                                                                        I didn’t see one. I think I clicked on man and didn’t see anything relevant, and then gave up and decided to email a patch.

                                                                                                                        Normally once you complete account registration you land on man’s index page, which has a (hopefully) attractive green button taking you to tutorials. Did something else happen for you?

                                                                                                                        1. 2

                                                                                                                          I don’t remember, sorry!

                                                                                                                          1. 4

                                                                                                                            Okay, no worries. I appreciate your feedback!

                                                                                                                    1. 2

                                                                                                                      I write in straight-up HTML all the time, thank you very much :)

                                                                                                                      1. 1

                                                                                                                        :-)

                                                                                                                      1. 1

                                                                                                                        I’m really excited about this project, but it appears that the build is currently broken. Do you have a stable release?

                                                                                                                        git clone https://git.sr.ht/~sircmpwn/aerc
                                                                                                                        Cloning into 'aerc'...
                                                                                                                        ...
                                                                                                                        make
                                                                                                                        go build  \
                                                                                                                        	-ldflags "-X main.Prefix=/usr/local" \
                                                                                                                        	-ldflags "-X main.ShareDir=/usr/local/share/aerc" \
                                                                                                                        	-o aerc
                                                                                                                        ...
                                                                                                                        # git.sr.ht/~sircmpwn/aerc/worker/imap
                                                                                                                        worker/imap/worker.go:115:29: w.worker.Logger.Writer undefined (type *log.Logger has no field or method Writer)
                                                                                                                        
                                                                                                                        1. 4

                                                                                                                          You need go 1.12 or newer.

                                                                                                                          1. 2

                                                                                                                            Ah, thanks!