git-appraise – Distributed Code Review for Git

• git-appraise

  10 5,092 2.3 Go

  Distributed code review system for Git repos

  

I believe their docs cover the scenario of reviewing someone's code by pushing your review to the git repo, and others can use `git appraise list` to see open pull requests.

https://github.com/google/git-appraise/blob/master/docs/tuto...

A trivial git-hook could be setup for automating email notifications.

• git-appraise-web

  2 213 0.0 HTML

  Web UI for git-appraise

  

I tried https://github.com/google/git-appraise-web, with a review made only locally, not pushed to the remote, but it doesn't seem to work. Did I miss something? I went up to accepting the request, so the command line is working, but the web GUI - at each step - only shows a closed request [0], and clicking on it gives an empty page.

[0] https://ibb.co/HTg8Jfc

• WorkOS

  workos.com sponsored

  The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.

  

• prr

  1 266 8.6 Rust

  Mailing list style code reviews for github

• git-from-the-bottom-up

  32 808 0.0

  An introduction to the architecture and design of the Git content manager

Very tangential:

Gerrit also stores some of its configs in a git repo. I was setting up a new instance, but couldn't get Admin permissions because the way my auth front-end didn't play well with the docker image's assumptions.

Gerrit already does a lot of its work via non-standard references. For example, you don't push to a branch, `refs/branches/foo`, you push to a separate `refs/for/foo` namespace that creates the review.

Similarly, Group config is stored in the All-Users git repo [1], but in references created after a UUID, in `refs/groups/UU/UUID`.

I ended up having a to exercise the plumbiest of plumbing commands [2] to create a new commit from scratch (from a tree, from the index, from blobs), to update the group ref to add myself to the Administrators group (this, of course, requires a local shell and permissions on the Gerrit host). It was a great way to exercise what I had learned in Git from the Bottom Up [3]

[1] https://gerrit-review.googlesource.com/Documentation/config-...

[2] https://git-scm.com/book/en/v2/Git-Internals-Git-Objects

[3] https://jwiegley.github.io/git-from-the-bottom-up/

• awesome-git-addons

  1 1,866 3.3

  :sunglasses: A curated list of add-ons that extend/enhance the git CLI.

please make a pull request to add this to awesome git lists, like https://github.com/stevemao/awesome-git-addons for example! this is so cool

• git-appraise-eclipse

  1 34 10.0 Java

  Discontinued Distributed code review for Eclipse

  

• git-issues

  1 259 10.0 Python

  A distributed issue tracking system based on Git repositories, written in Python

There was an attempt at some point to build decentralized issue tracking into git: https://github.com/duplys/git-issues

I was always a bit disappointed that it didn't catch on, but I realize it would require a UI and probably buy-in from companies like Github and Gitlab, whose whole business is based around the lack of these features in git, so it was DoA, unfortunately.

• InfluxDB

  www.influxdata.com sponsored

  Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.

  

• git-bug

  56 7,998 6.3 Go

  Distributed, offline-first bug tracker embedded in git, with bridges

As a sort of spiritual successor to git-appraise, I've been working on git-bug[1] which support issues and will at some point support kanban and code review. There is a few notables improvements:

- CRDT-like reusable data structure [2][3] for true p2p workflow and easily create new entities (code review ...)

- bidirectional bridges to github, gitlab ... to ease the transition or just use git-bug as a complement of those platform

- CLI, terminal UI and web UI, for different taste and integrate into your tooling/workflow

[1]: https://github.com/MichaelMure/git-bug

[2]: https://github.com/MichaelMure/git-bug/blob/master/doc/model...

[3]: https://github.com/MichaelMure/git-bug/blob/master/entity/da...

• asv

  3 840 9.1 Python

  Airspeed Velocity: A simple Python benchmarking tool with web-based reporting

  

> All these workflows are a derivation of the source in the repository and keeping them close together has a great aesthetic.

I agree. Version control is a great enabler, so using it to track "sources" other than just code can be useful. A couple of tools I like to use:

- Artemis, for tracking issues http://www.chriswarbo.net/blog/2017-06-14-artemis.html

- ASV, for tracking benchmark results https://github.com/airspeed-velocity/asv (I use this for non-Python projects via my asv-nix plugin http://www.chriswarbo.net/projects/nixos/asv_benchmarking.ht... )

• forgefed

  20 982 5.5 Bikeshed

  ForgeFed - Federation Protocol for Forge Services

  

> I agree that e-mail is not perfect, but... how is GitHub better?

Please look at my comment again. I prefer email to locked in forges.

> Devs like new shiny toys, and e-mails are old technology

There is one aspect where such forges have an advantage over email - a better user experience. Aerc and the likes all good - but Github and others provide a good user experience over a tool that everyone uses - the web browser.

> we should have something better than e-mail in 2023

We really should have something better than email. I'm saying this as someone who operates a personal mail server and a bunch of desktop services for it. It's really hard to get the setup correct.

In that context, it's worth looking at forgefed (https://forgefed.org/). It's a protocol for federating forges like Gitea and Gitlab. It's built on top of ActivityPub - which behaves a bit like email (it has inboxes and outboxes for every user). From the spec, it seems like pull requests happen by sending patches to the destination forge.

> Nobody takes the time to try the e-mail workflow (even though it's really two git commands)

Email workflow seems simple. But there are two things that make it complicated:

1. The patches don't specify the commits they apply to. It's simply assumed that they apply to the head of the main branch. The commits have to be carefully rebased on the main branch before sending the patches. It could otherwise lead to conflicts and a lot of wasted time.

2. Each commit/patch is send as a single email. Developers usually make frequent commits when they develop. Such patches can be confusing and hellish to review. A sane patchset requires the developers to edit the commit history, usually using interactive rebases. Each commit should contain a single feature and shouldn't break the build.

I consider both the above to be good development practices and follow them even on my personal projects. However, this is an additional barrier to entry. In fact, this may be a bigger problem for many than setting up git for email.

• local-code-review

  1 3 5.5 Shell

  Scripts to enable viewing a pull request as a local pending merge

Here's a script I use for this. It's designed for use with github. Run it in your copy of a repo with a PR number and it will create a 'review' branch that has the changes uncommitted. Works great with IDEs with a good diff experience.

https://github.com/whenceforth/local-code-review

Suggest a related project