On Wed Apr 23, 2025 at 12:23 AM CEST, Nico Williams wrote: > On Tue, Apr 22, 2025 at 04:17:03PM -0400, D. Ben Knoble wrote: >> On Wed, Apr 16, 2025 at 7:36 AM Remo Senekowitsch <remo@xxxxxxxxxxx> wrote: >> > On Mon Apr 14, 2025 at 9:54 PM CEST, D. Ben Knoble wrote: > > [Responding out of order.] > >> > I think it's the other way around: Building a code review UI built on >> > git and centered around interdiffs today is _hard_, that's why we don't >> > have it yet. Adding change-ids to commits will make it much easier, >> > paving the way for these tools to be implemented. >> >> Fair point, although GitHub's detection of force-pushes makes me think >> it could split a PR into versions at that point, cross-link backwards >> and forwards by one version (from the force-push detection), show >> range-diffs between versions based on the target branch of the merge, >> and even follow the cross-links to show an overall sequence of >> versions. > > GitLab does something like this for review comments where the author > updates the commented you get a link you can click on that shows you the > differences between version n-1 and version n. GitLab does this without > change IDs. > > GitLab seems to figure it out -- an existence proof that it can be done. > So maybe Junio and Theodore are quite right that similarity checks > should be enough. I haven't used GitLab in a while so I had to test it. I found the feature you describe and it's nice, but it falls short in important and somewhat predicable ways. Firstly, it only happens when you make a comment on the whole diff. Then it shows you an interdiff between the version you commented on and the immediate next version. (I didn't find a way to make it show the interdiff between the commented-on and the _latest_ version, but that seems doable implementation wise.) But that's not really what we're talking about here. That's taking the interdiff between two versions _of the entire branch_ and selecting a relevant _hunk_ from it. Neat, but completely unrelated. If you make a comment on a _specific commit_, the feature doesn't kick in at all. GitLab just tells you that this comment was made "on an outdated change in commit xyz". A truly patch-based review UI would show the interdiff between the previous version of the specific commit that was commented on and the next or latest version of _that specific patch_. That requires tracking how the individual patches evolve and as far as I can tell, GitLab makes no attempt to do so. I didn't even give it a hard time, I kept the number of commits, the commit messages and author timestamps the same. So, while I must say GitLab is doing pretty well here, claiming that they "figured out" patch-based review on top of git without change-ids is not accurate.
