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: https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks

EDIT: add link to git-hooks docs.

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

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.

They push to their own server and ask you to pull from there. See https://lkml.org/lkml/2023/6/25/128 for an example.

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

Yes I read that part. Read together, it reads that they chose a design because it allowed for a server-less setup. My point is that this is a stupid design requirement, because the feature is useless without a server.

I think it is more that no server side setup is needed beyond git to support this. That's to say regardless of the hosted git provider you may be using, they do not need special support for git-appraise.

As an aside, if I remember correctly you can also run git without any server at all with multiple contributors. But it isn't the most ergonomic!

Yes, I agree that's probably what they meant. And it's a good feature. But it's also not really decentralized. Git, in my opinion, can be decentralized. You can run git locally and get lots of benefits even if you don't use collaboration. Version history and branching being two such examples. But you can't really get any benefits from code review without a centralized place to pass the reviews through.

So because of your limited imagination or usage (or ignorance) of Git, this is "stupid" and "useless". Mmmmk.

Yes, virtually any decentralized technology can be used in a way that looks like centralization. But as a doctor might suggest, stop doing, to yourself, the thing that hurts.

The fact is, it's entirely possible to use git-appraise without a "centralized git server" just like it is possible to use... decentralized git precisely in such a manner.

Moreover, I can pretty much guarantee that whatever you think "really decentralized" would look like, could be used in basically the exact same ways as git-appraise.

What does it even mean for something to be decentralized if you're talking about using it on a single machine, with a single user? I just can't man, I can't.

Yep, you can push and pull directly to/from another person as long as it's not pushing to a branch they currently have checked out (and of course you have read/write access).

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

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.

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

Ok, good point.

I think they are referring to something like Gerrit. With this you could have a simple server configured with ssh to allow pushing.

You could also push directly to other people's repos, right? (They could configure it so they only allow pushes that create PRs)