Re: git rename/moved status unreliable in ruby

From: Junio C Hamano <gitster@pobox.com>
Date: May 5, 2026, 00:09 UTC
Message-ID: <xmqqecjqpvhw.fsf@gitster.g>
In-Reply-To: <CAPx1Gvd_VEWHrBWtUjNeWZ+wfmsAOTamKmL6fhBSQi=MbmXRcw@mail.gmail.com>

Chris Torek <chris.torek@gmail.com> writes:

> This is why -- and when -- making two separate commits, one with
> "exact same content for deleted-file-D vs added-file-A", followed by
> later changes to new file A, helps: if you compare the commit that has

"helps" -> "somtimes helps". Only when comparison is done step-wise (e.g., "git log -M/--follow" and "git rebase"), it may help, but in general, when comparison between only two endpoints matter (e.g., "git diff" and "git merge"), such an artificial breaking of a logically single change into two does not help.

Show 8 quoted lines

>> If this is considered something that can be improved ...
>
> It *could* be improved. Doing so in a way that works for more than
> just some special cases -- e.g., in a way that works for ordinary
> text, or graphical images, for instance, rather than just for Ruby
> sources (or just C sources, or C++, or Swift, or Python, or whatever)
> -- seems particularly tricky. Some degree of ignoring white-space
> changes would probably help multiple cases, though.

You could tie it with the attributes system to allow logic specialized for the nature of the contents. The beauty of the design decision to store "snapshots" is that these heuristics can be improved without having to change anything in the history that are cast in stone.