Subject: Re: git mv after the fact

From: Ben Knoble <[email-masked]>
Date: Thu, 28 May 2026 10:28:51 -0400

> Le 27 mai 2026 à 19:24, Junio C Hamano <[email-masked]> a écrit :
> 
> Chris Torek <[email-masked]> writes:
> 
>>> Chris Torek <[email-masked]> writes:
>>>> A flag for "git mv" would be convenient (and slightly moreefficient ...
>>> 
>> 
>> On Tue, May 26, 2026 at 8:09 PM Junio C Hamano <[email-masked]> wrote:
>>> May be convenient, but I do not get the "efficient" part.
>> 
>> A normal `git mv` renames the index entry and the file in the working
>> tree without running `git add` on the *contents*, so there's no new hash
>> computation.  Presumably a `git mv --after foo bar` would do the same: verify
>> that there is no existing `bar` in the index, that there is an existing `foo` in
>> the index, and that there is no `foo` but there is a `bar` in the working tree,
>> and then it would rename (add-and-remove, really, because of sorting)
>> the index entry, without scanning the working tree contents.
>> 
>> In other words, we skip reading the 3 terabyte file, or whatever.
> 
> Yup, that matches what I wrote.  We do not rehash and we only write
> the index just once.

One thing I wondered: if we don’t have an exact move but assume (by not hashing), doesn’t that mean the index would differ from what’s on disk? I originally thought that might be a problem, but the more I thought the more I realized that’s a fairly typical state anyway.

Just seemed like a potential footgun to me, but perhaps not worth worrying about.