From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: X-Spam-Status: No, score=-4.0 required=3.0 tests=ALL_TRUSTED,BAYES_00 shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id B9E3220248; Thu, 4 Apr 2019 09:55:22 +0000 (UTC) Date: Thu, 4 Apr 2019 09:55:22 +0000 From: Eric Wong To: meta@public-inbox.org Subject: repobrowse history and notes Message-ID: <20190404095522.qdp7ebznrl5resro@dcvr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline List-Id: I've always intended public-inbox for software development. It's useful for other types of communication, too, but software development was always the driving force. A web-based git viewing counterpart, known as "repobrowse" was envisioned and started several times over the years in different languages; one of which is in the historical "repobrowse" branch in public-inbox.git. I finally realized a few months ago that the world doesn't need another web-based git repository viewer; at least not in the traditional sense... Currently, I believe there are two types of repository viewers: 1. standalone repository viewers with no messaging: gitweb, cgit, etc... 2. repository viewers with centralized messaging: gogs/gitea, gitlab, and proprietary stuff public-inbox is a bit different: A centralization-resistant messaging system with git-awareness What public-inbox can do with code repositories, today: * reconstruct unmerged blobs using patches (SolverGit.pm) * show SolverGit-reconstructed blobs with syntax highlighting * diff-highlighting emails; hunk headers link to SolverGit endpoints * spawn/wrap cgit(1), including parsing the config * handle smart HTTP requests of coderepos with our git-http-backend(1) wrapper (since cgit doesn't handle smart clone/fetch) * search for blob object_ids (done YEARS ago :) SolverGit would not have been possible without this. Works-in-progress: * show diffs with different options (contexts, algorithms), most importantly to be able to diff against SolverGit-reconstructed blobs which aren't merged into a permanent+public code repo, yet. TODO: * show/link commits (like git-show(1), and link to emails/threads discussing such commits) * built-in/configurable search queries for common patterns git-request-pull(1) templates, patches for certain paths. Perhaps this could support generic reporting for building tables off CI emails, even. * show trees... * maybe: blame/annotate Solver-reconstructed blobs * spawn/wrap gitweb similar to what was done for cgit * display config information for mirroring/reproducing the site. * more tests One more general thing to keep in mind: public-inbox tries to be educational in its fight against centralization. For example, it includes instructions/examples for using git-send-email(1) to nudge users towards proper threading and reply-to-all behavior. Continuing that tradition, the git repository viewer section should try to be educational for users unfamiliar with git, patches, or emails in order to prepare users for offline use. Thus having links to git manpages, examples, etc could all be useful in the right places.