Live data from Hacker News

Git-appraise – Distributed Code Review for Git

github.com

21–30 of 173 posts

Re: Git-appraise – Distributed Code Review for Git

#22
Grain of salt: I've become a curmudgeon w.r.t software complexity over the last decade, but git is already distributed. What's wrong with patch email chains? Or the current existing wrappers around git that allows for distributed review chains (i.e. git(hub|lab), etc.)?

Re: Git-appraise – Distributed Code Review for Git

#24
Storing code review (and ci results, and analyzer runs) in git is a wonderful idea. All these workflows are a derivation of the source in the repository and keeping them close together has a great aesthetic. It also enables the 'single pane of glass' to observe the a pull request from.

Re: Git-appraise – Distributed Code Review for Git

#25
It looks like this tool integrates with git signing keys, so thats pretty rad. I was concerned when the readme and docs didn't mention signing, nor did the official git-notes documentation, but cloning the repo and grepping for "sign" shows they are supporting it! Guess that means no editing other peoples' review comments when their suggestions are too tedious :-D

Re: Git-appraise – Distributed Code Review for Git

#26

Grain of salt: I've become a curmudgeon w.r.t software complexity over the last decade, but git is already distributed. What's wrong with patch email chains? Or the current existing wrappers around git that allows for distributed review chains (i.e. git(hub|lab), etc.)?

> What's wrong with patch email chains?

Nothing (aside from the lack of UX/UI, but some might see this as a plus)

> Or the current existing wrappers around git that allows for distributed review chains (i.e. git(hub|lab), etc.)?

They are centralized. I must have access to github.com to do my review and when git(hub|lab|random-pet-project).com disappears, so do all the PR reviews.

Re: Git-appraise – Distributed Code Review for Git

#28
post #24

Storing code review (and ci results, and analyzer runs) in git is a wonderful idea. All these workflows are a derivation of the source in the repository and keeping them close together has a great aesthetic. It also enables the 'single pane of glass' to observe the a pull request from.

I assume it would also have the advantage of not tying the code reviews and PRs to a proprietary git provider.

Say I move from GitHub to GitLab, I assume I lose all the PR descriptions and comments people have made over the years and only keep the commit messages.

It would be nice to have a provider-agnostic representation of this data.

Re: Git-appraise – Distributed Code Review for Git

#29
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/heads/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 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/

Post reply on HN