Re: Semantics of change IDs (Re: Gerrit, GitButler, and Jujutsu projects collaborating on change-id commit footer)

From: Remo Senekowitsch <remo@buenzli.dev>
Date: Apr 23, 2025, 00:25 UTC
Message-ID: <D9DLAQTMJYU6.RJLLVMQZOICK@buenzli.dev>
In-Reply-To: <aAgWytQNqtLzg2TU@ubby>

On Wed Apr 23, 2025 at 12:23 AM CEST, Nico Williams wrote:

Show 26 quoted lines

> 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@buenzli.dev> 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.