Re: git mv after the fact

[Junio C Hamano <gitster@pobox.com>]

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

>> Chris Torek <chris.torek@gmail.com> writes:
>>> A flag for "git mv" would be convenient (and slightly moreefficient ...
>>
>
> On Tue, May 26, 2026 at 8:09 PM Junio C Hamano <gitster@pobox.com> 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.

> Anyway, comparing to `git rm --cached`:
>
>> I think the requested "feature" is not all that outrageous.  It
>> would be a similar value as a morning-after correction measure for
>> "oops, I moved the file in the filesystem without telling Git".
>
> I agree, but I also don't see it as valuable enough to bother
> writing a proper implementation.

Yup, I was merely agreeing with your "convenient" comment.  I do not
think it is such a high-priority item for any active developers
among us to drop something they are doing and writing it instead.