Re: git rename/moved status unreliable in ruby

From: Chris Torek <chris.torek@gmail.com>
Date: May 5, 2026, 00:46 UTC
Message-ID: <CAPx1GveSn30Ua6fD3ZhiRHiN+-DpcN=9FbUcY3GstiXz9UYZ_Q@mail.gmail.com>
In-Reply-To: <xmqqecjqpvhw.fsf@gitster.g>

On Mon, May 4, 2026 at 5:09 PM Junio C Hamano <gitster@pobox.com> wrote:

Show 6 quoted lines

> Chris Torek <chris.torek@gmail.com> writes:
>
> > This is why -- and when -- making two separate commits ... helps
>
> "helps" -> "somtimes helps".  Only when comparison is done step-wise
> (e.g., "git log -M/--follow" and "git rebase"), it may help,

That's why I said "and when". :-)

 > > ... Some degree of ignoring white-space

Show 7 quoted lines

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

Indeed. Something like Peff's suggestion might work, although I see some danger in ignoring white space completely. It would probably be better to compress "all leading but non-empty white space" to either nothing or a single space, eliminate all trailing white space, and compress other white space to a single blank.

(Though at the same time, when we're dealing with slugs extracted from very long single lines, this is probably wrong, so perhaps this should only be done for "intact single line" slugs. Then again it might not matter at this point.)

Doing this on binary files and programs written in Whitespace[1] would be wrong, of course. ;-)

Chris

[1]: https://en.wikipedia.org/wiki/Whitespace_(programming_language)