Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Git-appraise – Distributed Code Review for Git

github.com

Post reply on HN
Print view View original

41–50 of 173 posts

Re: Git-appraise – Distributed Code Review for Git

#41

Post by glodalitazic »

infogulch wrote: post #36
Arbortheus wrote: post #28

Earlier quoted context omitted.

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.

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.

do you have a link to a discussion?

Re: Git-appraise – Distributed Code Review for Git

#42

Post by radarsat1 »

raffraffraff wrote: post #34

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…

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

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

Update: looks like that link above was a separate attempt from [1] and [2]

[1]: https://github.com/dspinellis/git-issue

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

Re: Git-appraise – Distributed Code Review for Git

#43

Post by goku12 »

tuckerpo wrote: post #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.)?

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

Re: Git-appraise – Distributed Code Review for Git

#44

Post by jauco »

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

Re: Git-appraise – Distributed Code Review for Git

#45

Post by cloudhead »

raffraffraff wrote: post #34

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…

We’re working on this at https://radicle.xyz — a blockchain isn’t needed

Re: Git-appraise – Distributed Code Review for Git

#46

Post by _1tan »

raffraffraff wrote: post #34

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…

There's radicle.xyz, although it seems like they abandoned their old GUI and moved back to a CLI for now.

Re: Git-appraise – Distributed Code Review for Git

#47

Post by joachimma »

jauco wrote: post #44

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 ' for your editor and then look through the changes. Because you're comparing the working tree you can leave comments... by typing source…

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.

Re: Git-appraise – Distributed Code Review for Git

#48

Post by FPGAhacker »

jauco wrote: post #44

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 ' for your editor and then look through the changes. Because you're comparing the working tree you can leave comments... by typing source…

What did you do with all the comments at the end of the review?

Re: Git-appraise – Distributed Code Review for Git

#49

Post by F-W-M »

FPGAhacker wrote: post #48
jauco wrote: post #44

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 ' for your editor and then look through the changes. Because you're comparing the working tree you can leave comments... by typing source…

What did you do with all the comments at the end of the review?

If they are in there own commits, you just drop them.

Honestly the average level of git skills, doesn't allow such a workflow.

Re: Git-appraise – Distributed Code Review for Git

#50

Post by jauco »

joachimma wrote: post #47
jauco wrote: post #44

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 ' for your editor and then look through the changes. Because you're comparing the working tree you can leave comments... by typing source…

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.

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.

Post reply on HN