On Wed, Apr 09, 2025 at 11:02:41AM -0700, Junio C Hamano wrote: > Nico Williams <nico@xxxxxxxxxxxxxxxx> 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 --
