* repobrowse history and notes
@ 2019-04-04 9:55 Eric Wong
0 siblings, 0 replies; only message in thread
From: Eric Wong @ 2019-04-04 9:55 UTC (permalink / raw)
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
I finally realized a few months ago that the world doesn't need
another web-based git repository viewer; at least not in the
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.
* 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.
* 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
* 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.
^ permalink raw reply [flat|nested] only message in thread
only message in thread, back to index
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-04-04 9:55 repobrowse history and notes Eric Wong
user/dev discussion of public-inbox itself
Archives are clonable:
git clone --mirror http://public-inbox.org/meta
git clone --mirror http://czquwvybam4bgbro.onion/meta
git clone --mirror http://hjrcffqmbrq6wope.onion/meta
git clone --mirror http://ou63pmih66umazou.onion/meta
Newsgroups are available over NNTP:
note: .onion URLs require Tor: https://www.torproject.org/
AGPL code for this site: git clone https://public-inbox.org/ public-inbox