undefined | Better HN

0 pointsgen2205y ago0 comments

For huge diffs, there’s not much that beats `git checkout <branch> && git diff HEAD^`.

For leaving comments, pretty much every system I’ve used has issues. At work we use phabricator; the default settings are atrocious but they can be tuned to something workable.

I sometimes wonder how hard it would be to get diff reviews to be a first (or even second) class citizen of the git ecosystem. That way you can finally get the bliss of leaving review comments in the IDE. They already have “notes” which are vaguely similar, maybe it’s something they’re considering?

0 comments

bostik5y ago

> [git ecosystem] have “notes” which are vaguely similar, maybe it’s something they’re considering?

If you're referring to git-notes, they are ... kinda special. They are objects in their own namespace that reference the repository objects the notes themselves are attached to.

Sure enough, you can attach a note to any git-object. And you can view them either directly or from the git-log view. But the discoverability is lacking, and the UI of doing pretty much anything with git-notes is absolutely atrocious. Because they are in their own namespace, you don't automatically get them when you do a pull or fetch, which can get pretty confusing.

For the curious ones, the magic invocation needed to pull in updates to notes from the remote repo is:

    git fetch origin +refs/notes/*:refs/notes/*

Notes are not versioned, and you certainly don't get nice N-way merges between local and remote content. Semantics are different from regular git, and stuff can get lost.

So from where I'm looking at things, git-notes are not suitable for plumbing in a code review flow.

gen220OP5y ago

You're right, I was referring to git-notes and they aren't suitable as plumbing for code review :)

I was meaning to point out that we've developed plumbing for objects with "weaker" guarantees than source code, which can still be attached to refs. To me, this is indicative that the maintainers are willing to accept patches on things that are outside the "core mission" of versioning source code, and might mean that they're open to the idea of accepting a well-architected code review feature.

Although, you're also right, in that there's still a lot of plumbing to make sure that authors can only edit their own comments, and that sort of thing. The more I think about it, there's a lot of work to be done and it isn't easy.

But, if you made a proposal, I think git-notes is precedent for them accepting your contributions. :)

j / k navigate · click thread line to collapse