How GitLab does/doesn't need change IDs (was Re: Semantics of change IDs)

[Toon Claes <toon@iotcl.com>]

Nico Williams <nico@cryptonector.com> writes:

> On Wed, Apr 23, 2025 at 02:25:40AM +0200, Remo Senekowitsch wrote:

>> 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.)
>
> I suspect that's a UI design issue: how cluttered do you want the UI to
> be?  GitLab's UI is already quite cluttered.  Often I struggle to find
> the thing I want, and I use it often.

I'm not sure if you've been using Merge Requests here, but if you do you
can compare each version against another. There are two dropdowns near
the top of the "Changes" tab: "Compare <master> and <latest version>".
Here you can compare versions against the target branch and other
versions.

> I think GitHub and Gitlab both can handle ... commit ranges, can they
> not?  The problem is that then you have to find refs (or commit hashes)
> for each version you want to compare, and once again UI complexity gets
> ugly.

At GitLab we keep track of the commit IDs a branch has been (maybe only
if there is a Merge Request for that branch, I'm not sure). We can use
this information to compare versions. I think, to some people in this
thread, the use-case for Change-IDs is pretty similar: you want to tie
information about two commits together. If there is a branch, you have
this information, but in a mail-based workflow (or in Jujutsu) there is
no branch. In that case a Change-Id can fill that gap.

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

As I mentioned, you might need to create a MR to retain/see this
information, I'm not entirely sure.

> The point is that GL demonstrates that these things can be done.  And I
> don't see how a change ID would have helped GL much except in cases
> where one re-does all the commits with different subject lines etc, but
> leaves the actual patches mostly the same.  Now it does happen that I
> split and squash commits, but it's rare that I completely redo them.

That's because GL stores history about a branch ref (outside the Git
object/ref database). If you don't do that, you can't. Having a
Change-Id embedded in the commit, retains that information in Git's DB.

--
Toon