10 ms·

Git-appraise – Distributed Code Review for Git

253 points by pabs3 3y ago

gigatexal 3y ago
Needs a vscode plugin/integration
- rurban 3y ago
  There is an extra webui nearby, though. Similar to git-bug
  - thatguy27 3y ago
    I tried https://github.com/google/git-appraise-web 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 https://ibb.co/HTg8Jfc
rcme 3y ago
> This design removes the need for any sort of server-side setup. So what, I just write code reviews to myself? What happens when I want to review other peoples’ code? Where do I get it from? And when they want to read my comments, do I invite them over to my computer?
- matt-robertson 3y ago
  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/tutorial.md#sending-our-updates-to-the-remote-repository https://github.com/google/git-appraise/blob/master/docs/tuto... A trivial git-hook could be setup for automating email notifications: https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks EDIT: add link to git-hooks docs.
  - rcme 3y ago
    > 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. How do they push without a server to host the repository?
    - matt-robertson 3y ago
      Git uses a decentralized model where clients/servers are blurred and really only matter if you choose to create a "central" node of git as part of your workflow but you do not have to. More importantly, the significance to me is that it does not require any software other than git, which means I can use this approach independent of any git-hosting service. Especially moving between git-hosting services, it would be nice to have a standard way to operate pull requests.
    - pgeorgi 3y ago
      They push to their own server and ask you to pull from there. See https://lkml.org/lkml/2023/6/25/128 https://lkml.org/lkml/2023/6/25/128 for an example.
- predictabl3 3y ago
  It's in the first three paragraphs of the README... > By "distributed", we mean that code reviews are stored inside of the repository as git objects. Every developer on your team has their own copy of the review history that they can push or pull. Before the part you quoted. I feel like it'd be "nice" of me to suggest maybe you're being pedantic. Otherwise... ?
  - rcme 3y ago
    [flagged]
    - taberiand 3y ago
      You don't strictly need a central server, you just need an upstream path between the people involved in the PR. Eg if two developers both served up the same repo from their local machine, and each had an upstream to the other, then this would work as a distributed PR. And you could have any number of arbitrary nodes in that graph
      - deleted 3y ago
        [deleted]
      - rcme 3y ago
        No, that's not decentralized. If two people agree to use a "local" machine, then that local machine is a centralized server. If User A and B use User A's local machine, then User C has no choice but to use User A's local machine to participate in their code review. That's centralized.
        taberiand 3y ago
        You misunderstand me. In the example I gave, both developers serve the repository. Both developers connect to the other. It's peer to peer. A -- origin --> B A <-- origin -- B
        3y ago
ajma 3y ago
I know the main contributor to this. I'll flag him so he can answer any questions people might have.
pabs3 3y ago
A couple of other interesting projects in the code review space: https://github.com/crev-dev/ https://github.com/crev-dev/ https://github.com/danobi/prr https://github.com/danobi/prr
tuckerpo 3y ago
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.)?
- gouggoug 3y ago
  > 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.
- goku12 3y ago
  > What's wrong with patch email chains? The fact that it's email. There are two categories of problems with it: 1. It's been extended unnecessarily and implemented poorly. The biggest one in this category is HTML email. It's really hard to write mails using common clients without messing up mailing lists. Another problem is how badly email threading is displayed in these clients. Email UI is still abysmal. 2. Many features of emails are an afterthought. Email obviously arose when E2EE, privacy features, attachments and spam prevention were not big concerns. When they got eventually added, they added too many moving parts, complexity and lack of enforcement. I wish there was a modern successor to emails (immutable federated messaging) with less components, standard and mandatory E2EE and signing, built-in list support and spam management features. None of this is to say that git did it wrong. Even with all these problems, I still prefer the freedom offered by email to being tied-in to specific platforms.
  - palata 3y ago
    > Another problem is how badly email threading is displayed in these clients. Email UI is still abysmal. Fair point. However, given that the current alternative is "use another service entirely (e.g. GitHub)", I think it would be fair to assume that devs could choose a good e-mail client and learn how to format such e-mails correctly. It works for Linux, for instance. I started using Aerc, and I love it: https://aerc-mail.org/ https://aerc-mail.org/ > Many features of emails are an afterthought. I agree that e-mail is not perfect, but... how is GitHub better? With e-mail, you can send your patch encrypted (e.g. with PGP) if you feel the need, but otherwise it will go over HTTPS (same as GitHub). I honestly don't really know about attachments (I guess you would encrypt them with PGP as well?), but again, attachments on GitHub are not E2EE... I tend to believe that people use GitHub for different reasons, for instance: 1. It is the first thing they see when they join the industry 2. Cargo-cult, a little bit 3. Devs like new shiny toys, and e-mails are old technology ("we should have something better than e-mail in 2023", which I disagree with). 4. Nobody takes the time to try the e-mail workflow (even though it's really two git commands). Actually it is common to not really take the time to learn the basic tools, I feel.
tandav 3y ago
TIL there's git notes https://git-scm.com/docs/git-notes https://git-scm.com/docs/git-notes
- karthie_a 3y ago
  is quite useful when you do some thing and want to notifiy your future self why you did things the way it is instead of comments you can use notes. Also you can generate metrics with notes if all commits are attached with notes.
bhawks 3y ago
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.
- Arbortheus 3y ago
  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.
  - infogulch 3y ago
    I seem to recall the gitea project working on something like git-tracked metadata (PRs, issues, etc), at least the idea has been floating around for a while. One problem with this idea that I haven't seen a good solution for is serializing issue numbers across distributed forks. Maybe we would give up nice sequential numbers and settle for hashed issue refs.
    - glodalitazic 3y ago
      do you have a link to a discussion?
    - yurishimo 3y ago
      We could also hash the issue with a time sensitive UUID. Then they could be ordered but unique to each person assuming they don't create an issue in the same microsecond.
  - palata 3y ago
    > It would be nice to have a provider-agnostic representation of this data. Isn't the (original) e-mail workflow exactly that? Git was designed for it.
craftkiller 3y ago
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
KolmogorovComp 3y ago
Looks neat in theory, but in practice how is the experience? Can anyone who used it give some feedback?
- ortichic 3y ago
  I mean... Just look at how to comment some line: `git appraise comment -f README.md -l 2 -m "Ah, so that's what this is" 1e6eb14c8014`
  - alkonaut 3y ago
    That is hopefully managed by a plugin to vscode or a web app. Git feels like the substrate, appraise the middle layer, and for mot use cases an UI would be added on top. Unlike regular git where command line is surprisingly useful despite being an awful mess (It's just hard to make better tools for many git tasks), I don't think command line code reviews would be the primary user interface.
  - hnben 3y ago
    there is a web interface [1] and also an eclipse plugin [2]. It would be nice if there was an intellijplugin as well. [1] https://github.com/google/git-appraise-web https://github.com/google/git-appraise-web [2] https://github.com/google/git-appraise-eclipse https://github.com/google/git-appraise-eclipse
AceJohnny2 3y ago
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-groups.html https://gerrit-review.googlesource.com/Documentation/config-... [2] https://git-scm.com/book/en/v2/Git-Internals-Git-Objects https://git-scm.com/book/en/v2/Git-Internals-Git-Objects [3] https://jwiegley.github.io/git-from-the-bottom-up/ https://jwiegley.github.io/git-from-the-bottom-up/
- Corsome 3y ago
  > Gerrit also stores some of its configs in a git repo. So does gitolite where the config (repos, user's SSH keys etc) is stored completely in a git repo. Perfect for migration, backup, audits. https://gitolite.com/gitolite/index.html https://gitolite.com/gitolite/index.html
deknos 3y ago
please make a pull request to add this to awesome git lists, like https://github.com/stevemao/awesome-git-addons https://github.com/stevemao/awesome-git-addons for example! this is so cool
raffraffraff 3y ago
Would it be possible to build a gitlab-like ui that is completely decentralized? Instead of depending on (or paying $$$ for) some web UI that wraps standard git functionality, could we run something completely locally that keeps repos/branches in sync and provides the basic merge/comment/review functionally that most people use? In other words, let me host the most basic git server in the world and put the complexity at the client? Edit: I wondered about using a separate Blockchain to maintain consensus on the "central" representation of the repo that we get from a "git server". This answer is useful, I think I'll digest it and ponder some more... https://stackoverflow.com/a/59509859 https://stackoverflow.com/a/59509859 Edit2: I also wondered if anyone implemented git server as an extremely thin layer on top of s3, but the only project I found was abandoned many years ago.
- radarsat1 3y ago
  There was an attempt at some point to build decentralized issue tracking into git: https://github.com/duplys/git-issues 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. Update: looks like that link above was a separate attempt from [1] and [2] [1]: https://github.com/dspinellis/git-issue https://github.com/dspinellis/git-issue [2]: https://github.com/MichaelMure/git-bug https://github.com/MichaelMure/git-bug
- cloudhead 3y ago
  We’re working on this at https://radicle.xyz https://radicle.xyz — a blockchain isn’t needed
- _1tan 3y ago
  There's radicle.xyz, although it seems like they abandoned their old GUI and moved back to a CLI for now.
- mike_hearn 3y ago
  What's wrong with a $5 VPS and using your IDE as the git UI?
glodalitazic 3y ago
For years i am thinking already about building an ide plugin for this. There is an eclipse implementation, but I'd love to have intellij. Leaving the ide for code reviews is a no-go. I started looking into adapting the intelij github plugin for this, or the gerrit plugin but didn't succeed yet. If someone is interested in collaborating we can open an org and a repo. a vscode plugin and maybe integration into gitea would be nice as well. Edit: there is https://github.com/thigg/appraise-intellij https://github.com/thigg/appraise-intellij but this is a mere POC
- glodalitazic 3y ago
  I could also imagine to store metadata from the ide next to the pr. The ide knows a lot of things about the change when doing refactorings that do not trivially reflect in the diff. E.g. Extractions and renamings... if I could do a review and the system would tell what happened instead of what changed in some cases, that would be so useful. never ever reviewing 1000 lines of class renamings anymore...
guideamigo_com 3y ago
- Last commit in April 2022. - Build status refers to non-existant Travis-CI Is this is a trustworthy project? Or just a cool experiment?
- henryaj 3y ago
  It's a Google project, but looks like it's abandoned/feature-complete.
CorrectHorseBat 3y ago
A bit tangential, does anyone know of a code review tool which allows to comment on lines that are not in the diff?
- procrastitron 3y ago
  This one does. You can comment on any line in any file.
jauco 3y ago
I have this "one weird trick" that I think is great, but somehow no-one else wants to use: At one point I worked with a fellow dev where we did PR reviews just as commits on top of the branch. So you'd check out their feature branch, run the equivalent of 'compare working tree with <main>' for your editor and then look through the changes. Because you're comparing the working tree you can leave comments... by typing source code comments (we used '// RVW(jauco)' to mark them). You can fix typo's just by, well, fixing the typo and you share the review by pushing to the branch. I found it to have the following advantages - PR comments usually break when you rebase or merge (because they reference a line number). These obviously won't, at worst there will be a merge conflict that you handle the obvious way. - If your PR comment requests explanation then the answer needs to be moved from the PR to the codebase, for future use. Writing comments in code means that you just need to clean up the conversation into a comment (or you can just leave it) - You can use a proper text editor for writing the comments - You can use code navigation while reading the changes (like, go to definition etc) - Because of these the review gets a more active feel. You're more inclined to engage with the code rather then just reading it while leaning back in your chair However, people tend to look at me like I'm crazy for suggesting something like this. OTOH tools like this look completely crazy to me. Why do all this work to get a worse version of something you already have?
- joachimma 3y ago
  If you leave the comments, doesn't the code get cluttered? If you remove the comments, don't you lose information? I could see this being useful if there was a script, that moved the comments out into either the commit message or a separate file.
  - jauco 3y ago
    Oh, yeah I didn't explain that part. In GH you'd click "resolve" to mark a discussion as finished. Here you just remove the comments to do the same (they're still in the git history, so you don't loose them forever) This doesn't need to be an extra step. If the comment is something like: "potential null pointer here" you can just fix the bug and remove the comment in one go, the reviewer will see what you changed from their comment commit so you don't loose information. In some cases the discussion is in the code until right before the merge when the PR author removes the block of comments. Often by summarising it into one comment for future readers who might have the same questions. But that's not more work than resolving comments in github. Not that you're looking through the changes anyway and your editor is open at the change _in edit mode_ so reading and editing isn't two separate steps.
michaelmure 3y ago
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 https://github.com/MichaelMure/git-bug [2]: https://github.com/MichaelMure/git-bug/blob/master/doc/model.md https://github.com/MichaelMure/git-bug/blob/master/doc/model... [3]: https://github.com/MichaelMure/git-bug/blob/master/entity/dag/example_test.go https://github.com/MichaelMure/git-bug/blob/master/entity/da...
palata 3y ago
Reading the comments, I am quite surprised to see no mention of the git e-mail workflow. Git was designed for it, but somehow it seems like it has been completely forgotten. Drew Devault has nice posts about it: https://drewdevault.com/2018/07/02/Email-driven-git.html https://drewdevault.com/2018/07/02/Email-driven-git.html https://drewdevault.com/2022/07/25/Code-review-with-aerc.html https://drewdevault.com/2022/07/25/Code-review-with-aerc.htm...
- nsteel 3y ago
  https://news.ycombinator.com/item?id=37085273 https://news.ycombinator.com/item?id=37085273 and https://news.ycombinator.com/item?id=37086360 https://news.ycombinator.com/item?id=37086360
brtknr 3y ago
Looks great! What this now needs is a nice Web UI and also convince major players to adopt it. It would be in their interest to assure users that they can take their data with them (even though most people probably wouldn't).
Groxx 3y ago
Yay git notes! I've been meaning to dig into building something exactly like this with them, because I hate how reviews and comments are basically a lock-in mechanism. There's a lot of room for building interesting stuff with notes, because they let you attach data to commits (and therefore files, lines, etc) without changing the SHA. E.g. got a question about a change months after it's committed? You can add a note to it, and now everyone can benefit from the Q&A. IMO it has just been missing a killer feature implementation or two, to spread knowledge that it exists and get more tools to expose them. They're invisible on GitHub's UI, for instance.
dolmen 3y ago
That project isn't actively maintained. For example: - Go dependencies are not kept up to date - the install instruction is from a GOPATH environment not from Go module style which is now the default for 2+ years now.
- uxp8u61q 3y ago
  Just look at the latest commits, issues and PRs.
zamalek 3y ago
How does this interact with rebases? If it's attached to git objects surely the notes will detach when the object hash changes?
- alchemist1e9 3y ago
  No responses is worrying. I’m also in the heavy rebase workflow pattern and would be huge problem if rebase breaks it.
  - procrastitron 3y ago
    Rebases are supported; you have to do the rebases through git-appraise in order for it to know that the original and rewritten commits are related.
bstpierre 3y ago
Maybe it happens a lot and nobody has mentioned it here yet, but I find live, out-of-band reviews are often very effective. By this I mean looking at a patch and asking questions or raising issues with the author. I do this fairly regularly for PRs at work where the “live” aspect is just slack (I work remotely). A dozen or so years ago I worked at a startup using svn and all reviews were like this: generate a diff, post a link to the diff on jabber, someone will comment/question. There’s room for immediate back and forth as needed. Revise, approve, done. Very lightweight, yet effective. However we were all colocated and all of the team members were high functioning so I’m not sure if it generalizes. (Also, being colocated meant that occasionally the jabber conversation could move to f2f with whiteboards if things got complicated.)
worldsavior 3y ago
Awesome.
backendanon 3y ago
This sounds like something that already existed out there I've read about in the past. Either way, this lets me out: "Assuming you have the Go tools installed" Not interested in Go or anything else that gives Google control over the world, or any of the FAANG.
DaanTimmerman 3y ago
[dead]
Hannsh 3y ago
[dead]
gedw99 3y ago
This is cool. I wonder is there is the same thing for Issues ? Maybe git notes ?
AbeniJohnson555 3y ago
[dead]
AbeniJohnson555 3y ago
[dead]
Bistrong22 3y ago
[flagged]
AilsaD 3y ago
[dead]

253 points by pabs3 3y ago

gigatexal 3y ago

Needs a vscode plugin/integration

rurban 3y ago
There is an extra webui nearby, though. Similar to git-bug
- thatguy27 3y ago
  I tried https://github.com/google/git-appraise-web 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 https://ibb.co/HTg8Jfc

rcme 3y ago

> This design removes the need for any sort of server-side setup. So what, I just write code reviews to myself? What happens when I want to review other peoples’ code? Where do I get it from? And when they want to read my comments, do I invite them over to my computer?

matt-robertson 3y ago
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/tutorial.md#sending-our-updates-to-the-remote-repository https://github.com/google/git-appraise/blob/master/docs/tuto... A trivial git-hook could be setup for automating email notifications: https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks EDIT: add link to git-hooks docs.
- rcme 3y ago
  > 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. How do they push without a server to host the repository?
  - matt-robertson 3y ago
    Git uses a decentralized model where clients/servers are blurred and really only matter if you choose to create a "central" node of git as part of your workflow but you do not have to. More importantly, the significance to me is that it does not require any software other than git, which means I can use this approach independent of any git-hosting service. Especially moving between git-hosting services, it would be nice to have a standard way to operate pull requests.
  - pgeorgi 3y ago
    They push to their own server and ask you to pull from there. See https://lkml.org/lkml/2023/6/25/128 https://lkml.org/lkml/2023/6/25/128 for an example.
predictabl3 3y ago
It's in the first three paragraphs of the README... > By "distributed", we mean that code reviews are stored inside of the repository as git objects. Every developer on your team has their own copy of the review history that they can push or pull. Before the part you quoted. I feel like it'd be "nice" of me to suggest maybe you're being pedantic. Otherwise... ?
- rcme 3y ago
  [flagged]
  - taberiand 3y ago
    You don't strictly need a central server, you just need an upstream path between the people involved in the PR. Eg if two developers both served up the same repo from their local machine, and each had an upstream to the other, then this would work as a distributed PR. And you could have any number of arbitrary nodes in that graph
    - deleted 3y ago
      [deleted]
    - rcme 3y ago
      No, that's not decentralized. If two people agree to use a "local" machine, then that local machine is a centralized server. If User A and B use User A's local machine, then User C has no choice but to use User A's local machine to participate in their code review. That's centralized.
      - taberiand 3y ago
        You misunderstand me. In the example I gave, both developers serve the repository. Both developers connect to the other. It's peer to peer. A -- origin --> B A <-- origin -- B
        3y ago

ajma 3y ago

I know the main contributor to this. I'll flag him so he can answer any questions people might have.

pabs3 3y ago

A couple of other interesting projects in the code review space: https://github.com/crev-dev/ https://github.com/crev-dev/ https://github.com/danobi/prr https://github.com/danobi/prr

tuckerpo 3y ago

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.)?

gouggoug 3y ago
> 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.
goku12 3y ago
> What's wrong with patch email chains? The fact that it's email. There are two categories of problems with it: 1. It's been extended unnecessarily and implemented poorly. The biggest one in this category is HTML email. It's really hard to write mails using common clients without messing up mailing lists. Another problem is how badly email threading is displayed in these clients. Email UI is still abysmal. 2. Many features of emails are an afterthought. Email obviously arose when E2EE, privacy features, attachments and spam prevention were not big concerns. When they got eventually added, they added too many moving parts, complexity and lack of enforcement. I wish there was a modern successor to emails (immutable federated messaging) with less components, standard and mandatory E2EE and signing, built-in list support and spam management features. None of this is to say that git did it wrong. Even with all these problems, I still prefer the freedom offered by email to being tied-in to specific platforms.
- palata 3y ago
  > Another problem is how badly email threading is displayed in these clients. Email UI is still abysmal. Fair point. However, given that the current alternative is "use another service entirely (e.g. GitHub)", I think it would be fair to assume that devs could choose a good e-mail client and learn how to format such e-mails correctly. It works for Linux, for instance. I started using Aerc, and I love it: https://aerc-mail.org/ https://aerc-mail.org/ > Many features of emails are an afterthought. I agree that e-mail is not perfect, but... how is GitHub better? With e-mail, you can send your patch encrypted (e.g. with PGP) if you feel the need, but otherwise it will go over HTTPS (same as GitHub). I honestly don't really know about attachments (I guess you would encrypt them with PGP as well?), but again, attachments on GitHub are not E2EE... I tend to believe that people use GitHub for different reasons, for instance: 1. It is the first thing they see when they join the industry 2. Cargo-cult, a little bit 3. Devs like new shiny toys, and e-mails are old technology ("we should have something better than e-mail in 2023", which I disagree with). 4. Nobody takes the time to try the e-mail workflow (even though it's really two git commands). Actually it is common to not really take the time to learn the basic tools, I feel.

tandav 3y ago

TIL there's git notes https://git-scm.com/docs/git-notes https://git-scm.com/docs/git-notes

karthie_a 3y ago
is quite useful when you do some thing and want to notifiy your future self why you did things the way it is instead of comments you can use notes. Also you can generate metrics with notes if all commits are attached with notes.

bhawks 3y ago

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.

Arbortheus 3y ago
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.
- infogulch 3y ago
  I seem to recall the gitea project working on something like git-tracked metadata (PRs, issues, etc), at least the idea has been floating around for a while. One problem with this idea that I haven't seen a good solution for is serializing issue numbers across distributed forks. Maybe we would give up nice sequential numbers and settle for hashed issue refs.
  - glodalitazic 3y ago
    do you have a link to a discussion?
  - yurishimo 3y ago
    We could also hash the issue with a time sensitive UUID. Then they could be ordered but unique to each person assuming they don't create an issue in the same microsecond.
- palata 3y ago
  > It would be nice to have a provider-agnostic representation of this data. Isn't the (original) e-mail workflow exactly that? Git was designed for it.

craftkiller 3y ago

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

KolmogorovComp 3y ago

Looks neat in theory, but in practice how is the experience? Can anyone who used it give some feedback?

ortichic 3y ago
I mean... Just look at how to comment some line: `git appraise comment -f README.md -l 2 -m "Ah, so that's what this is" 1e6eb14c8014`
- alkonaut 3y ago
  That is hopefully managed by a plugin to vscode or a web app. Git feels like the substrate, appraise the middle layer, and for mot use cases an UI would be added on top. Unlike regular git where command line is surprisingly useful despite being an awful mess (It's just hard to make better tools for many git tasks), I don't think command line code reviews would be the primary user interface.
- hnben 3y ago
  there is a web interface [1] and also an eclipse plugin [2]. It would be nice if there was an intellijplugin as well. [1] https://github.com/google/git-appraise-web https://github.com/google/git-appraise-web [2] https://github.com/google/git-appraise-eclipse https://github.com/google/git-appraise-eclipse

AceJohnny2 3y ago

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-groups.html https://gerrit-review.googlesource.com/Documentation/config-... [2] https://git-scm.com/book/en/v2/Git-Internals-Git-Objects https://git-scm.com/book/en/v2/Git-Internals-Git-Objects [3] https://jwiegley.github.io/git-from-the-bottom-up/ https://jwiegley.github.io/git-from-the-bottom-up/

Corsome 3y ago
> Gerrit also stores some of its configs in a git repo. So does gitolite where the config (repos, user's SSH keys etc) is stored completely in a git repo. Perfect for migration, backup, audits. https://gitolite.com/gitolite/index.html https://gitolite.com/gitolite/index.html

deknos 3y ago

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

raffraffraff 3y ago

Would it be possible to build a gitlab-like ui that is completely decentralized? Instead of depending on (or paying $$$ for) some web UI that wraps standard git functionality, could we run something completely locally that keeps repos/branches in sync and provides the basic merge/comment/review functionally that most people use? In other words, let me host the most basic git server in the world and put the complexity at the client? Edit: I wondered about using a separate Blockchain to maintain consensus on the "central" representation of the repo that we get from a "git server". This answer is useful, I think I'll digest it and ponder some more... https://stackoverflow.com/a/59509859 https://stackoverflow.com/a/59509859 Edit2: I also wondered if anyone implemented git server as an extremely thin layer on top of s3, but the only project I found was abandoned many years ago.

radarsat1 3y ago
There was an attempt at some point to build decentralized issue tracking into git: https://github.com/duplys/git-issues 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. Update: looks like that link above was a separate attempt from [1] and [2] [1]: https://github.com/dspinellis/git-issue https://github.com/dspinellis/git-issue [2]: https://github.com/MichaelMure/git-bug https://github.com/MichaelMure/git-bug
cloudhead 3y ago
We’re working on this at https://radicle.xyz https://radicle.xyz — a blockchain isn’t needed
_1tan 3y ago
There's radicle.xyz, although it seems like they abandoned their old GUI and moved back to a CLI for now.
mike_hearn 3y ago
What's wrong with a $5 VPS and using your IDE as the git UI?

glodalitazic 3y ago

For years i am thinking already about building an ide plugin for this. There is an eclipse implementation, but I'd love to have intellij. Leaving the ide for code reviews is a no-go. I started looking into adapting the intelij github plugin for this, or the gerrit plugin but didn't succeed yet. If someone is interested in collaborating we can open an org and a repo. a vscode plugin and maybe integration into gitea would be nice as well. Edit: there is https://github.com/thigg/appraise-intellij https://github.com/thigg/appraise-intellij but this is a mere POC

glodalitazic 3y ago
I could also imagine to store metadata from the ide next to the pr. The ide knows a lot of things about the change when doing refactorings that do not trivially reflect in the diff. E.g. Extractions and renamings... if I could do a review and the system would tell what happened instead of what changed in some cases, that would be so useful. never ever reviewing 1000 lines of class renamings anymore...

guideamigo_com 3y ago

- Last commit in April 2022. - Build status refers to non-existant Travis-CI Is this is a trustworthy project? Or just a cool experiment?

henryaj 3y ago
It's a Google project, but looks like it's abandoned/feature-complete.

CorrectHorseBat 3y ago

A bit tangential, does anyone know of a code review tool which allows to comment on lines that are not in the diff?

procrastitron 3y ago
This one does. You can comment on any line in any file.

jauco 3y ago

I have this "one weird trick" that I think is great, but somehow no-one else wants to use: At one point I worked with a fellow dev where we did PR reviews just as commits on top of the branch. So you'd check out their feature branch, run the equivalent of 'compare working tree with <main>' for your editor and then look through the changes. Because you're comparing the working tree you can leave comments... by typing source code comments (we used '// RVW(jauco)' to mark them). You can fix typo's just by, well, fixing the typo and you share the review by pushing to the branch. I found it to have the following advantages - PR comments usually break when you rebase or merge (because they reference a line number). These obviously won't, at worst there will be a merge conflict that you handle the obvious way. - If your PR comment requests explanation then the answer needs to be moved from the PR to the codebase, for future use. Writing comments in code means that you just need to clean up the conversation into a comment (or you can just leave it) - You can use a proper text editor for writing the comments - You can use code navigation while reading the changes (like, go to definition etc) - Because of these the review gets a more active feel. You're more inclined to engage with the code rather then just reading it while leaning back in your chair However, people tend to look at me like I'm crazy for suggesting something like this. OTOH tools like this look completely crazy to me. Why do all this work to get a worse version of something you already have?

joachimma 3y ago
If you leave the comments, doesn't the code get cluttered? If you remove the comments, don't you lose information? I could see this being useful if there was a script, that moved the comments out into either the commit message or a separate file.
- jauco 3y ago
  Oh, yeah I didn't explain that part. In GH you'd click "resolve" to mark a discussion as finished. Here you just remove the comments to do the same (they're still in the git history, so you don't loose them forever) This doesn't need to be an extra step. If the comment is something like: "potential null pointer here" you can just fix the bug and remove the comment in one go, the reviewer will see what you changed from their comment commit so you don't loose information. In some cases the discussion is in the code until right before the merge when the PR author removes the block of comments. Often by summarising it into one comment for future readers who might have the same questions. But that's not more work than resolving comments in github. Not that you're looking through the changes anyway and your editor is open at the change _in edit mode_ so reading and editing isn't two separate steps.

michaelmure 3y ago

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 https://github.com/MichaelMure/git-bug [2]: https://github.com/MichaelMure/git-bug/blob/master/doc/model.md https://github.com/MichaelMure/git-bug/blob/master/doc/model... [3]: https://github.com/MichaelMure/git-bug/blob/master/entity/dag/example_test.go https://github.com/MichaelMure/git-bug/blob/master/entity/da...

palata 3y ago

Reading the comments, I am quite surprised to see no mention of the git e-mail workflow. Git was designed for it, but somehow it seems like it has been completely forgotten. Drew Devault has nice posts about it: https://drewdevault.com/2018/07/02/Email-driven-git.html https://drewdevault.com/2018/07/02/Email-driven-git.html https://drewdevault.com/2022/07/25/Code-review-with-aerc.html https://drewdevault.com/2022/07/25/Code-review-with-aerc.htm...

nsteel 3y ago
https://news.ycombinator.com/item?id=37085273 https://news.ycombinator.com/item?id=37085273 and https://news.ycombinator.com/item?id=37086360 https://news.ycombinator.com/item?id=37086360

brtknr 3y ago

Looks great! What this now needs is a nice Web UI and also convince major players to adopt it. It would be in their interest to assure users that they can take their data with them (even though most people probably wouldn't).

Groxx 3y ago

Yay git notes! I've been meaning to dig into building something exactly like this with them, because I hate how reviews and comments are basically a lock-in mechanism. There's a lot of room for building interesting stuff with notes, because they let you attach data to commits (and therefore files, lines, etc) without changing the SHA. E.g. got a question about a change months after it's committed? You can add a note to it, and now everyone can benefit from the Q&A. IMO it has just been missing a killer feature implementation or two, to spread knowledge that it exists and get more tools to expose them. They're invisible on GitHub's UI, for instance.

dolmen 3y ago

That project isn't actively maintained. For example: - Go dependencies are not kept up to date - the install instruction is from a GOPATH environment not from Go module style which is now the default for 2+ years now.

uxp8u61q 3y ago
Just look at the latest commits, issues and PRs.

zamalek 3y ago

How does this interact with rebases? If it's attached to git objects surely the notes will detach when the object hash changes?

alchemist1e9 3y ago
No responses is worrying. I’m also in the heavy rebase workflow pattern and would be huge problem if rebase breaks it.
- procrastitron 3y ago
  Rebases are supported; you have to do the rebases through git-appraise in order for it to know that the original and rewritten commits are related.

bstpierre 3y ago

Maybe it happens a lot and nobody has mentioned it here yet, but I find live, out-of-band reviews are often very effective. By this I mean looking at a patch and asking questions or raising issues with the author. I do this fairly regularly for PRs at work where the “live” aspect is just slack (I work remotely). A dozen or so years ago I worked at a startup using svn and all reviews were like this: generate a diff, post a link to the diff on jabber, someone will comment/question. There’s room for immediate back and forth as needed. Revise, approve, done. Very lightweight, yet effective. However we were all colocated and all of the team members were high functioning so I’m not sure if it generalizes. (Also, being colocated meant that occasionally the jabber conversation could move to f2f with whiteboards if things got complicated.)

worldsavior 3y ago

Awesome.

backendanon 3y ago

This sounds like something that already existed out there I've read about in the past. Either way, this lets me out: "Assuming you have the Go tools installed" Not interested in Go or anything else that gives Google control over the world, or any of the FAANG.

DaanTimmerman 3y ago

[dead]

Hannsh 3y ago

[dead]

gedw99 3y ago

This is cool. I wonder is there is the same thing for Issues ? Maybe git notes ?

AbeniJohnson555 3y ago

[dead]

AbeniJohnson555 3y ago

[dead]

Bistrong22 3y ago

[flagged]

AilsaD 3y ago

[dead]