Refusing to use PRs
Refusing to use PRs
Posted Jan 13, 2026 12:04 UTC (Tue) by alx.manpages (subscriber, #145117)In reply to: Refusing to use PRs by donald.buczek
Parent article: Evans: A data model for Git (and other docs updates)
>
> Hmm, I don't know. You've come up with a personal standard that is more of a hindrance than a help to a potential reviewer. How is anyone supposed to know what it means?
That is a project where I contribute often and I help co-maintain. Maintainers know what to expect.
> Where is revision “v1”?
What I'm showing are range-diffs, so that if you've reviewed a previous revision, you know what changed for the next one.
v1 would compare to /dev/null, but that wouldn't be useful, since you're new to the patch set, so you need to review the entire PR at whatever revision it is.
> Why are there suddenly “b” and “c” variants in ‘v5’ but no “a”?
v5 is v5a. I differentiate minor revisions from major ones, so that reviewers know to expect unimportant changes there. That focuses attention on the major revisions.
> Which version was or is now in the PR branch?
The latest, of course. In that case, v5c.
> In terms of content, there is free text under the versions, which is good, but then there is a privately defined git command (“git rd”) that has no clear meaning for anyone else and a list of commits where it is also unclear what they should be used for.
When I contribute to other projects, I use regular `git range-diff ...`. But in this project, people know what me and what it means. After all, the names I give to branches and remotes locally are not useful to reviewers. What counts is the commit hashes, which are still visible, and of course the diffs.
> You might be better off sticking to the standard of the respective project instead of your personal one.