user/dev discussion of public-inbox itself
 help / color / Atom feed
* 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)
  To: meta

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 (

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

^ 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
	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:

AGPL code for this site: git clone public-inbox