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

[Nico Williams <nico@cryptonector.com>]

On Wed, Apr 09, 2025 at 11:02:41AM -0700, Junio C Hamano wrote:
> Nico Williams <nico@cryptonector.com> writes:
> 
> > I don't find file rename heuristics to be "simple", and they're often
> 
> I think you need to re-read what Tytso wrote before reacting.  He
> never said rename and copy heuristics is simple.  His statement was
> that choosing *NOT* to record the "file A was renamed to B and C was
> copied to D in this commit" in commit objects can be thought as a
> choice to keep the system simple.

I was using file rename heuristics to explain that I wouldn't like more
of the same for other things; I was not trying to litigate renames.

I'm trying to litigate the _addition_ of more similarity-based
heuristics for _other_ things.

If similarity heuristics were enough for CR tools then none would have
introduced anything like change IDs.  Or perhaps CR tools authors have
been flat out wrong to not try or use similarity heuristics exclusively
over change IDs.  That's a topic worth discussing.  I've stated my
preference for not relying solely on similarity heuristics.

> [...]
> 
> But recording that as a copy may be a *wrong* thing to do in the
> first place.  The IDE cannot guess *why* you copied F to G in the
> first place.  [...]

Exactly, software can't read human minds, which is why recording
user-expressed intent (rename, copy) would be a nice option to have.

> If you inspect the resulting change brought in by the commit, with
> intelligence, a human may say "G is a completely new file, even
> though it shares the leading boilerplate comment with F and every
> other file in the project".  Your IDE wouldn't say that.

Right, the IDE should let one rename/copy the file _and_ choose to ether
record that as a rename/copy in the version control system _or not_.

Only the user can truly know their own intent.

Sometimes users may slip up and not record their intent correctly,
perhaps because going back to fix an earlier choice is ETOOHARD to
figure out how to do in their IDE's UI.  Fair enough.  So similarity
checks can help one understand history, but where one can have intent
recorded, that's a better indicator.  IMO.

> We designed not to etch such wrong renames/copoies in stone by
> recording them at the commit time.  Instead we compare the before
> and after image to intuit the _intention_ of what the user wanted to
> do _when_ you _ask_ (i.e. when you run "git diff" or "git log").

Well, I suspect more likely that Linus didn't want to have some sort of
inode number nor some sort of explicit rename/copy indication as a
significant simplification that allowed Git to get shipped sooner.  I'm
not questioning that nor trying to litigate rename/copy.

Nico
--