Re: git mv after the fact

From: Chris Torek <chris.torek@gmail.com>
Date: May 27, 2026, 03:19 UTC
Message-ID: <CAPx1GvetxY1T7cuFN_xe51EURr-ED2BqW3E82jj90ko3PSYSyg@mail.gmail.com>
In-Reply-To: <xmqqy0h5lfa0.fsf@gitster.g>

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

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.

I did write it up as a shell script though, long ago. Adding it here via gmail would mess with white space so I'll just provide a link to the file on GitHub:

https://github.com/chris3torek/scripts/blob/master/git-mv-after

Chris