1. 81
  1.  

  2. 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.

    2. 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).

      2. 3

        This is pretty awesome and the output is really convincing. I really love that, even if it means a lot has to be done in order to use it in language X.

        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.

            2. 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.