1. 45

  2. 16

    Similar page on git.sr.ht:


    Someone sent me this thread and suggested I comment on my design perspective with sourcehut. I agree that GitHub is too fluffy, generally speaking, and Gitlab has much of the same. I generally focus on giving the content as much real estate as I can and minimizing distractions. Anything which isn’t the content should either (1) be immediately relevant to the content, like the file mode and path, or (2) be useful in the context of that content, like the tabs to explore the rest of the repo in question, or the breadcrumbs to different files/dirs in that file’s path. There is a list of links in the nav, but they’re all directing you to tools, not marketing material, and are colored as to not be distracting (contrast with Github’s large attention-grabbing bar).

    On other pages I use colors to stronger effect. I use the shades of grey approach for almost everything on the page, but if there’s one thing you probably came to that page to do (for example, creating a new git repo on the index page), it’s given a colored button. I use red for dangerous buttons, too. I also lay out explicitly in the text of the button what pushing it will do - prefer “Proceed and delete” over “Continue”. Icons are used conservatively throughout, but interactive elements always have text next to them stating their purpose (rather than relying on the user’s interpretation of the icon to explain), and non-interactive icons are seldomly used without accompanying text, and always with a tooltip that explains their meaning.

    Overall my philosophy is that sourcehut is a tool for engineers. These pages are almost never seen outside of when you’re in engineering mode. When you’re in engineering mode, I just want to put the information you need at hand and not distract you with enterprise, pricing, stars & forks, etc. There’s a dedicated marketing page for that stuff.

    It’s not perfect, but I’m pretty happy with it and I get generally positive feedback. Worth noting that it’s missing some features GitHub has, like per-file logging and git blame. Happy to take feedback if anyone here has some.

    1. 8

      Just FYI, I find per file history an essential part of web view. It’s the number one reason I use github or cvsweb.

      I have taken an interest in some file. I want to see its evolution. Alas, command line tools are pretty terrible. It’s very easy to get a short listing of commits and change messages, but now I want to see the diff, which requires running another command, and copying and pasting hex hashes, etc. (git log -p will dump too much output on me, I don’t want to see every diff ever.) And same for annotate. Also, there’s much less friction for me to split out a dozen tabs for a dozen diffs in a browser than trying to do the same in a terminal.

      Most other operations, like viewing and searching files, navigating directories, I can handle pretty well from the command line.

      1. 8

        Have you tried tig? http://jonas.nitro.dk/tig/

        I find it a great console tool for browsing git histories. It’s also very nice for viewing a single file’s history. Just run tig path/to/file.

        1. 1

          Thanks so much for the suggestion, this looks really cool! For the record, here’s the updated link.

          1. 1

            Oh, thank you. I had no idea, but after a few minutes this appears to be just what I want.

            (For cvs I’ve gone so far as to build my own, but it’s pretty rough since I have little patience polishing terminal UI elements.)

          2. 4

            Yeah, I get that. It’s not a deliberate omission, it’s just a product of limited time and a new product.

            1. 1

              I look forward to seeing your platform grow! It may not yet have the kitchen sink, as they say; but it certainly has a very principled & well-designed foundation, and that gives me great confidence in the quality of the kitchen sink that will eventually be installed. 😉

          3. 4

            I don’t have anything particularly constructive to say other than that UI looks perfect for exactly the reasons you describe: “engineering mindset”, content-first, minimal noise.

            1. 3

              And the corresponding page for a given ref (tag): https://git.sr.ht/~sircmpwn/git.sr.ht/tree/0.22.7/.builds/archlinux.yml Clearly shows in the UI that one is browsing 0.22.7 tree, not for example master.

            2. 9

              Let’s look at the git ui…

                 git [--version] [--help] [-C <path>] [-c <name>=<value>]
                     [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]
                     [-p|--paginate|-P|--no-pager] [--no-replace-objects] [--bare]
                     [--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>]
                     <command> [<args>]


              1. 14

                I prefer to use the one true git porcelain: https://magit.vc/

                Popup and dwim commands
                 A Cherry-picking    b Branching         B Bisecting
                 c Committing        d Diffing           D Change diffs
                 e Ediff dwimming    E Ediffing          f Fetching
                 F Pulling           l Logging           L Change logs
                 m Merging           M Remoting          o Submodules
                 O Subtrees          P Pushing           r Rebasing
                 t Tagging           T Notes             V Reverting
                 w Apply patches     W Format patches    X Resetting
                 y Show Refs         z Stashing          ! Running
                 & Magit-LFS         % Worktree
                Applying changes
                 a Apply          s Stage          u Unstage
                 v Reverse        S Stage all      U Unstage all
                 k Discard
                Essential commands
                 g     refresh current buffer
                 TAB   toggle section at point
                 RET   visit thing at point
                 C-h m show all key bindings
                1. 3

                  So you are saying we need a whole new set of porcelain

                  1. 4

                    It means that back in the day (when git alternatives were viable) the cohort of github users were self-selected for being willing to put up with shitty UI.

                    1. 1

                      I meant that I’d rather stick back to the raw pipes whenever some GUI is getting too much in our way.

                  2. 4

                    The lack of the branch selector on the history page is an oversight. Can’t really agree with anything else though. Why would you not want global operations on every page?? o_0

                    1. 5

                      Because they take up real-state. I don’t think the author is arguing against having global operatorations in general, rather what they choose as a global operatoration, the equivalent of the like button. Meanwhile operations like the cloning the repo can only be accessed from the ‘main’ page. Or they hide the ref of the PR, making it harder for people to download the branch of the pull request.

                    2. 6

                      I guess the author has not used truly horrible UIs like Collabnet. I once sent a link to a file to someone on email. It had all sorts of junk in the URL and after a while clicking on the link did not produce the intended result.

                      90% of the time I’m on this page, I’m looking for the history button

                      Not me. When I am on a page looking at the code, I need to see the code

                      And 90% of the time, it takes me 30 seconds to find it. I would love to get a hold of the analytics for how many people star a repository after looking at a random file buried somewhere in the tree

                      30 seconds is possibly an exaggeration. But it is possible that the star button is not removed because of PJAX : https://github.com/defunkt/jquery-pjax. It is probably why Github UI seems ( to me at least ) very fast

                      Also missing: any way to even get back to the file

                      Try the back button on your browser

                      1. 8

                        Try the back button on your browser

                        Sad state of affairs when the back button has been practically killed off by web UIs.

                        My personal banks don’t deal with it at all, though the bank I use for my company fortunately does. Lots of governmental sites break or deny when going back.

                        Some sites explicitly tell you not to hit back, as if the developers never heard of idempotence.

                        Wonder if this started with having html elements with a javascript call to go back?

                        1. 0

                          90% of the time I’m on this page, I’m looking for the history button

                          Not me. When I am on a page looking at the code, I need to see the code

                          You are really just saying the same thing. Both the code and the history button are under several rows of UI stuff.

                          Try the back button on your browser

                          Good luck. It may work on shithub for now, but many sites break catastrophically when you hit the magic destroy^W back button.

                          1. 12


                            I don’t think you should use shithub. At best it is an annoying addition that doesn’t add anything to your statement and at worst it reduce it to a childish rant and shows you don’t want to engage in serious discussion.

                            1. 2

                              yeah let’s not do the Micro$haft stuff from the late 90s lol

                              1. 4

                                MICROS~1 is my favourite from that era. But yeah, it’s all dumb.

                                1. 3

                                  I hadn’t heard that one before, and found a great explanation from a relic of an internet past… https://everything2.com/title/MICROS~1

                                  1. -1


                                    Ha, this one should be allowed for historic purposes.

                          2. 3

                            Another oddity: where have all the doodleheads gone?

                            …What is a doodlehead?

                            If the author is just referring to emoji, then no, I do not wish for emoji to litter the GitHub UI.

                            Infantilism is pernicious enough in our industry already.

                            1. 6

                              He’s joking about that row of committer avatars. Its utility from a code reader perspective is debatable, but Github wants to be more than a source code repository, it wants to be a coding social network.

                              From that perspective, the doodleheads make sense, they incentivize people. People are extremely vain, I’ve managed Internet forums and you wouldn’t believe what can motivate people. Sometimes it’s something as ridiculous as a bunch of stars or a numeric rating or a photo displayed prominently on the code repository page of a project they like.

                            2. 2

                              I hope all of this gets fixed when the Microsoft facelift is out.

                              1. 2

                                Either you use the word “fixed” with a fair share of sarcasm, or… “you must be new here” :-)

                                1. 1

                                  it was sarcasm :-)

                                  1. 1

                                    you got me then :-)

                              2. 1

                                The summary is good and frankly I’ve put some thought on how would a good git browser interface looked like.

                                I’d gladly see some mockups with the issues author identified fixed.

                                1. 1

                                  No mockup needed, it already exists.