Git-appraise – Distributed Code Review for Git
github.com
github.com
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?
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.
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.
Honestly the average level of git skills, doesn't allow such a workflow.
Maybe the key required for this is that you have reviews where, if code prompts a question, then more often then not the code should change. At the very least to explain briefly why this approach was chosen over another approach.
If you have code reviews from developers with differing skill levels and the response to the question is just an explanations how the language or framework works then this might become a bit cumbersome (because you have to leave the comment to reply and then remove the whole discussion before merging)
Reviews on some projects will ask you to make a commit/patch in between your third and fourth (out of seven). And to fix a typo in the fifth commit message. And do fix something in the second commit that leads to conflicts in the next commits. And then to end up with for example seven commits that each “do one thing” or whatever. So if the expectation is that you end up with one “fixed up“ commit at the end of the review process which encapsulates the whole PR then this won't work.
With your approach I imagine going in several rounds where
1. Reviewers leave comments
2. I address them
3. I publish that as review round X
4. I “clean up“ the history (get rid of comments/all review history) and address things like “make a doc commit before commit number 4”
5. Publish that as the “blank slate” (no comments) for the next round
6. Invite the reviewers to the next round
And that could work.
Something more dynamic/less rigorous (with rounds) and you might end up with an excessive amount of history rewriting and conflict resolution.
I guess you can do a similar thing with issues just by having a folder of markdown files for each issue and appending comments to them.
If some conventions could be agreed you could have GUI support.
1. Click the fetch icon. New work to review shows up.
2. Right click to compare the branches, take a look through the diffs.
3. If I see something I want to check, click "Checkout" in the branch selector and start making the changes, commit, push.
4. Otherwise when done, use git merge and delete the origin branch (I have some shell functions for this).
One thing I've found hard to settle on is what message to use in the merge commits. I don't insist all changes have tickets because it'd just be redundant work for the case of small cleanups, fixing bugs you spotted whilst doing other stuff. But then the default merge commit message isn't terribly helpful, and writing one that is can end up redundant.
Another problem is that the railway lines can get quite hairy if people aren't disciplined about constantly rebasing. You can of course rebase for them, but then you lose the ability to view only the merge commits to master.
We use a kernel model in which there is no shared repository, so it's impossible for branches to be merged without being reviewed because it's the reviewer who merges them when they're satisfied.
Thanks for sharing!
https://youtu.be/MUqvXHEjmus Transcript: https://www.janestreet.com/tech-talks/janestreet-code-review...
However, I got a feeling it wouldn't scale well to large teams. Specifically because you have to manually keep very strict about not mixing reviewed and unreviewed code, and if you do it's hard to disentangle them and decide what's in scope for a review.
Of course, that becomes a non-issue if you use a squash merge approach, instead of retain all commits (which in this approach have a lot more of a "WIP" feel to it).
Do code review comments have value after merging? I would also posit they're easier to find if they're in an external location (like github/lab, gerrit, etc), unless you also wrote tools that can figure out which commits and comments belong to a certain feature.
1. `git log --first-parent --pretty=oneline` will show you merge commits but not the commits that were merged. If your merge commits have non-default messages, this effectively makes for a "flat" log in which CR commits don't appear. Unfortunately not all git GUIs support this (e.g. github).
2. If a comment genuinely isn't actionable with a code change take the discussion to another forum (email, slack, or for recording, the issue tracker). Then once the design disagreement is resolved, go back to using CR comments.
In the case it is or it really needs an explanation it stays in the codebase, otherwise you take it, e.g. to GitHub issues or PR comments.
Another thing that's easy, but often overlooked: putting relevant URLs in comments. The best comments explain why some approach was taken; linking to a discussion on JIRA, or the Stack Overflow answer we c̶o̶p̶y̶-̶p̶a̶s̶t̶e̶d̶ ̶f̶r̶o̶m̶ used as inspiration, is (a) quicker than writing a whole explanation, and (b) gives better evidence of what's going on (e.g. that the CTO explicitly asked for this-or-that; or that the SO question now has a better answer; etc.)
If I want to know why something was done, I expect to be able to use git log or git blame on the file or line and get find a commit message, issue tracker link or pull request reference that I can pursue.
Sometimes even longer :)
is my all time favorite.
Simple example: say a comment points out some issue with the changes (say, lack of unit test on feature a), author could say that emulating scroll events in unit tests is complex and the mocks provide no real value to actual in-browser behavior.
This comment is something you may want to remove for the final merge or add a TODO: in the code, or leave the comments as a discussion for future but meanwhile push so prod people can test, etc.
You could move these comments to your saas git provider tools (e.g. github issues or comments or wiki for the final merge).
In any case the thing I like about this approach is that essentially *forces* users to actually checkout the damn thing and go through its code. I think this is something I would really want to test out with my team. I have a junior coming soon to my team (it's his first project and employment ever, he's 18), and I will test this approach with him and see how it works before I propose it to some of my peers and seniors.
The advantage of this kind of approach is it doesn't require any special tooling, but could certainly be made easier with special tooling.
Solves that issue entirely. Let branches hold their history, let the release/main branch hold the history of stable builds.
I regularly use "git blame" on lines of code to try and figure out what the specific reasoning was on a line of code. I'm going to have a very different interpretation depending on if the resulting commit says "implement feature xyz" vs "fix issue abc on feature xyz".
Squash murders that added context. At best you're optimizing for the wrong thing, and worst it's outright vandalism.
1. Broken intermediate commits hamper git bisect.
2. Fixup commits are noisy in git log, git blame, etc.
Note: there's zero issue with NON-BROKEN, NON-FIXUP commits. Separating large changes is even preferable for the reasons you stated.
---
tl;dr Broken intermediate commits are bad; whole intermediate commits are good.
The idea is that you just send your patch by e-mail, and the reviewer just applies it with `git am <the patch>`. So you don't even have to sync on a branch. Then the reviewer can comment directly on the patch. You answer with new versions of the patch, and get new reviews. It's minimal, actually decentralized (unlike, say, GitHub), and I believe it has the advantages of your workflow above.
Nice posts about it:
https://drewdevault.com/2018/07/02/Email-driven-git.html
https://drewdevault.com/2022/07/25/Code-review-with-aerc.htm...
This is a nice tutorial, too, but I would recommend reading Drew Devault's posts first (and watching his short videos):
So the reviewer receives the commits, with their descriptions, authors, everything. Just like pulling a branch, really.
Source: https://git-scm.com/docs/git-format-patch#_base_tree_informa...
A question I have with the process is: can email based workflow still work with for a continuous integration/delivery pipeline?
Doesn't sourcehut already support that? (https://man.sr.ht/builds.sr.ht/)
Same :-). I also love how people don't have to create an account to send a patch. They just need to send me an e-mail. That is not a problem on GitHub (because everybody is forced to have an account there), but it is if you want to host your repo somewhere else.
> can email based workflow still work with for a continuous integration/delivery pipeline?
SourceHut has a CI feature integrated with the mailing-lists: https://man.sr.ht/builds.sr.ht/
You always have to enforce some kind of conventions, but I wouldn't say GitHub is the most flexible. With an e-mail workflow, everyone can use the e-mail client they want and review the patches the way they want, without being forced to sign up on a website at all.
You can do reviews in a separate clone, to avoid interrupting any changes you're making (reading the diff only needs a 'git fetch', so won't interfere with anything; but making changes is easiest with a full check-out).
You could use 'git worktree' to manage that; but I'm happy with 'git clone' and 'rm -r'.
How do you deal with conflicts between multiple reviewers?
I think I like the idea that in an e-mail, I can really comment on some patch, and then the author of the patch can decide what to do with it. Maybe the author modified the patch in the meantime, but they will know if my comment is still valid or not. Without me having to handle the conflicts.
I'm thinking mostly about leads who have a lot to review. They probably don't want to have to fix conflicts in comments all the time.
But still it puts the burden on the reviewer rather than on the patch author. And the reviewer's time is never less precious. If you need a review from Linus Torvalds, I think it makes sense to make it as seamless as possible for him. And that is what the e-mail workflow does, I would say.
Why? Because unblocking my teammates is the most important thing I can do, and I expect the same from my teammates. I never want the reason our team is late to be "I had more important things to do" because (cliché incoming), "the is no 'I' in 'team'".
A reviewers time isn't more valuable than mine, and my time is no more valuable than anyone else (assuming accountants don't exist). If changing 3 lines is really an issue, then create a merge-tool for this workflow and add it to your git configuration file.
> If changing 3 lines is really an issue, then create a merge-tool for this workflow and add it to your git configuration file.
Or use the e-mail workflow, where the lead can just comment on the patch right away, without having to even pull the branch (and worse, push comment and potentially fix conflicts), right?
But on a team, I’d say there is no Most Valuable Player.
• It yields much more collaborative code reviews, because for small tweaks it's quicker to just fix the thing you want changed than ask someone else to do it. After all, you've already got the code checked out and in your IDE. This is especially true when working with easily refactorable languages like Java or Kotlin and IDEs with great diff viewing support like IntelliJ, because if you don't like the symbol name someone picked you just change it. No need for a round-trip. This is huge because it stops reviewers/reviewees getting exhausted from "nitpicking" and fosters teamwork.
• You can see the IDE's static analysis outputs, which you won't see in a web based PR viewer. This can often let you spot bugs that might otherwise escape notice.
• You can easily run the unit tests, or add a quick test if you notice it's missing. If it fails, no problem, just commit the failing test, push and let the author know that they have more work to do.
To implement this workflow we use Gitolite on our "HQ" server that we use for everything. Everyone gets their own UNIX user and their own personal git clone of the product repos. Access controls are in force, so if you want someone to review something you push it into their repo but it has to be under a branch named rr/$PUSHER_USERNAME/change-name. So your PR queue is visible in your IDE's git branch explorer. Do a fetch and new work shows up to review, add commits or merge it and then delete the branch to close the review. The merge preserves the history of the review session.
We have it wired up to TeamCity and YouTrack (yup, I'm a JetBrains fan). Everyone also gets their own private TeamCity project. The combination of this means that devs can push private branches to get things nice and clean in CI without disturbing anyone else or polluting their UIs - there are no "draft PRs" or other self-contradictory concepts in this workflow. Ownership of branches is always crystal clear also, even for experimental branches or projects. Once a PR is merged into the tech lead's master branch, YouTrack notices the commit has gone green there and parses issue update commands out of the commit message, finally updating or closing the ticket automatically.
Note that this setup is cheap for small teams. TC and YouTrack are free for small setups, Gitolite is open source, all you need is a server. We pay 90 EUR a month for a dedicated machine at Hetzner that has 128 GB of RAM and 2TB NVMe flash, and everyone gets a UNIX user, so if you want to do remote dev on it or host random files you can do so and it's extremely fast.
Socially this arrangement is kernel-like. The tech lead of the project runs the repo from which releases are done and merge in from teammates, which in turn can merge in from their teammates and so on. Ownership is always clear because the act of merging is also the act of taking responsibility. You can't get a tragedy of the commons where juniors keep picking other juniors to review their work like you can in more conventional free-for-alls.
Sure, but I feel like there's a big disadvantage here in that the person who did the bad thing isn't actively involved in fixing it. They lose out on acquiring that muscle memory. If this is a Sr. reviewing another Sr.'s PR and it's just a few minor oversights, fine. But if this is a Sr. reviewing a Jr.'s PR and they fix like 10 things in one commit, that seems harmful to the inexperienced dev's development. They don't even get a chance to ask why or provide clarification.
And if it comes off like a bunch of nitpicking, that's a person who likely really needs a little handholding. The whole "give a man a fish vs teach" proverb.
For example, if a junior isn't familiar enough with the standard library and misses a trick, you can try to explain in words what the better way is, or you can just fix it and then ask them to study the diff. I don't know what's better for long term learning, but at least you have the option.
If someone keeps making the same errors and isn't paying attention to the fixes you can just talk about it with them in a meeting, same as with any other recurring problem you might have with a teammate.
The model we implement is hierarchical, so there's no running roughshod over other people by design. If the reviewer isn't happy they won't merge, and you have to keep going until they are. But, it's also on the reviewer to get the work in because they're being held accountable for delivery too, and they can make changes with the same tools as the authors. So it's a collaboration.
I've been doing this for 26 years at 15 companies and have led several teams. I can think of some where this would be fine (ie. everyone has a healthy amount of EQ), but I can think of several with talented but somewhat thorny, opinionated sr level engineers where this would be a problem. I once had to have a talk with someone on the spectrum who would occasionally do this very thing because it was more expedient than explaining in a PR. The person who complained felt like they were being disrespected.
I think the way you work is very interesting. We once discussed about having a process that is more kernel-like.
The fact that everyone has their own remote clone of the (or all) git repositories, does that not introduce overhead? We did that long time ago when we started with git, but thought it introduced extra overhead without any benefit. I assume you do it to make the ownership clear? And I also assume that everyone in your team is very comfortable with git? (yes, I do think developers should know their tools inside-out, but that is sadly rarely the case)
Can you explain in more detail the steps for a code review process? Is it the author that creates and deletes the review branch in the clone of the reviewer? How does the author know that the reviewer finished the review? Is it always the author who pushes his code to the technical lead for merge into master?
Yes, it makes ownership clear and prevents code from being merged without being reviewed. GitHub offers CODEOWNERS files but often ownership doesn't map neatly to source code layout (and nor should it).
Most devs have not been comfortable enough with git to do this when they first joined but they learned quickly enough, and I helped them learn. The operations needed aren't that complicated. For example you don't need to do rebases in this workflow. It's just branching and pushing.
I should write up a proper blog post on the workflow. The code review author creates the branch by pushing into the reviewer's repository. The reviewer deletes the branch once they merge it. The author knows the review was finished because the code either gets merged, or it gets another commit on top that adds requests for changes. The branch in the reviewer's repository is where collaboration happens once the review process starts.
As long as there's an agreed upon comment format, it's really easy for the reviewee to find all the comment and adress them one by one.
I don't remember any drawbacks really, but we were a small team and the reviews were mostly "one on one".
git merge --no-commit --no-ff pr-branch
Am I missing an easier workflow/command to achieve the above? (Granted this is not so bad, and was suggested by GPT4, but I wondered if there might be a more straightforward way)
I am using a pull request flow currently, but have some annoyances:
- I nearly always check out the branch to review (I use a separate worktree with git worktree for this) so that I can explore the code and changes using my IDE; it is annoying to have to switch back and forth between IDE and PR interface to add comments;
- Sometimes I want to do a global review of some part of the code. This is typically not supported out of the box with review systems based on PRs. Sometimes you can work around that by creating dummy branches, but it is annoying;
- Sometimes there are interesting explanations but those are typically "lost"; yes, they are still somewhere in the PR system that was used at the time, in some pull request, tied to a commit hash that is no longer there, because the feature branch was rebased before merge; seriously, once the PR is merged everything that was commented and discussed is lost in practical terms;
So, yeah, I am tempted to try this approach with leaving comments in the code for the author of the branch. I believe it would also make the code review process more efficient.
- 2023-08-10.00.notes.md
- 2023-08-10.01.notes.md
- 2023-08-11.00.changelog.md
- 2023-08-11.01.changelog.md
- 2023-08-11.00.review.md
- 2023-08-11.01.review.md
- 2023-08-11.02.review.md
- 2023-08-11.00.project.md
This is all the value, isn't it?
Anything that forces the "reviewer" to become an "editor" suddenly massively increases the value of the "review."
People like the GitHub workflow because... then they don't have to do that work.
This is fine. I'm not sure how worse developers become better ones, except by fixing their mistakes. So if you're a huge corporation and you have the luxury to have a lot of redundant, in-training employees, many fresh out of school with no useful experience, great, reviews by senior people, so long as the junior person's code isn't actually written for them, can transmit some training value.
> However, people tend to look at me like I'm crazy for suggesting something like this
If you're a tiny startup and you have a junior developer, you've sort of already screwed up haven't you? Either you want to train them, and that's a huge mistake because you don't have the bandwidth for that. Or you do their work for them, which is like, why have them around at all then?
Just from your comment, I can see: * People don't get notifications about new review requests across dozens of repos * No good way to just get a list of remaining comments (I guess you grep the diff for RVW?) * Hard to set up "require all comments to be resolved before merging"
These could be automated easily with scripts and git hooks though, then it would be a pretty good flow.
Sure, there's still discussion when needed, but otherwise take it as a collaborative effort where you're asynchronously pair-programming.
[1] https://chelseatroy.com/2019/12/18/reviewing-pull-requests/
- 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...
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.
Isn't the (original) e-mail workflow exactly that? Git was designed for it.
But that may be a future problem, after all, removing a branch from a git repository (and its history) is fairly straightforward.
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... )
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.
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.
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.
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:
> 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.
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.
Maybe, but e-mail is here, the whole world knows and uses it, and even if it is not perfect, I think it does the job pretty well (put aside the fact that managing a server is hard).
> However, this is an additional barrier to entry.
Agreed. I just feel like we keep pushing the barrier down, but at some point, professionals need to learn the basics. I don't feel like we need more software in our world. We need better software. And if people can't learn their tools, I don't know if we can seriously expect them to write good software...
Last time I suggested [1] an approach to learning and taming the git CLI, somebody said that they want to design and write code, rather than learn too much CLI-fu. Big projects like Linux and Emacs can get away with requiring their contributors to learn the tools well enough. However, many developers may decide to avoid contributing rather than learn the tool, if the project is a small one.
Again, I agree with what you say - that's what I practice too.
Think about a junior joining a company. Through the first weeks they get: to be useful you need to learn about dependency management, git, frameworks we use, data stores we use, processes for review, our ci approach, our release approach, ...
Adding yet another process your work depends on, is fiddly to setup and doesn't have good docs online really isn't great. "We can add this on top, it's just basics" can really add up with enough systems.
That's the thing. In my view, you say "we should keep adding wrappers on top of wrappers and libraries on top of libraries, such that juniors can quickly get productive, but nobody actually understands what they are doing anymore and the smallest executable takes 50MB".
I say "we should reduce the number of dependencies such that one can understand the system better, even if it means that juniors need to spend time learning the basics".
Of course there is a balance to find (not everybody needs to master assembly), but the modern way, IMHO, goes too much towards productivity, and not enough towards mastering ones tools.
Same here :-). I have come to think that old and simple technology was nice, and the trend nowadays is to pile up a lot of complexity for no apparent reason.
> What's wrong with patch email chains?
I genuinely believe that most developers (who I believe have less than 5 years experience) have never seen the e-mail workflow in their life. And there is a tendency to believe that newer is better, so they don't even consider e-mail.
For me, being able to edit the patch request without spamming everyone on the email list would be nice. Making changes to the patch request requires convention to link them together.
The patch requests are completely decoupled from the git repository so now you need something else to generate the mailing list.
When comparing a PR tab in GH to mailing list patch requests, it should be obvious which one is better at reading/searching/linking previous patches.
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
So does gitolite where the config (repos, user's SSH keys etc) is stored completely in a git repo. Perfect for migration, backup, audits.
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
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.
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]
There's nothing special about a "git server": you can clone/push/pull/etc. from any checkout you like (apart from shallow clones, which may not have the requested commits). You can do this using local file paths, or over SSH, or over HTTP, etc. For example, here's an old blog post describing my git setup (pushing commits between folders on my laptop, and syncing those to multiple mirrors (a self-hosted static file server and GitHub) when online): http://www.chriswarbo.net/blog/2015-06-06-more_git.html
You might declare that some particular clone is the central repo for some project, but nobody has to care what you say: everyone's free to push/pull from each other, or send patches over email, regardless of what you've written on some blockchain or website. That's an advantage of git!
Edit: If you want a verifiable mechanism to know what X considers to be the canonical version of Y, you can use "whichever commit of Y that's signed by X has the highest timestamp". That may work better with more anonymous p2p transports like https://github.com/dhappy/git-remote-ipfs https://scuttlebot.io/apis/community/git-ssb.html
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.)
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.
Drew Devault has nice posts about it:
https://drewdevault.com/2018/07/02/Email-driven-git.html
https://drewdevault.com/2022/07/25/Code-review-with-aerc.htm...
a vscode plugin and maybe integration into gitea would be nice as well.
Edit: there is https://github.com/thigg/appraise-intellij but this is a mere POC
`git appraise comment -f README.md -l 2 -m "Ah, so that's what this is" 1e6eb14c8014`
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.
[1] https://github.com/google/git-appraise-web [2] https://github.com/google/git-appraise-eclipse
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?
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.
How do they push without a server to host the repository?
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.
> 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... ?
Not interested in Go or anything else that gives Google control over the world, or any of the FAANG.
- Last commit in April 2022.
- Build status refers to non-existant Travis-CI
I wonder is there is the same thing for Issues ? Maybe git notes ?