git mv after the fact

git mv after the fact

[Frieder Hannenheim]

Hi,

I'd like to propose a new flag for git mv, that updates the index
like git mv normally would but does not move the file. This would come
in handy when the file has already been moved, or is renamed by some
external tool and the user wants to fix up the index afterwards.

Thank you for considering this.

Sincerely,
Frieder Hannenheim

Re: git mv after the fact

[Chris Torek]

On Tue, May 26, 2026 at 6:18 AM Frieder Hannenheim <mail@fhannenheim.net> wrote:
> I'd like to propose a new flag for git mv, that updates the index
> like git mv normally would but does not move the file. ...

You may already know this, but technically no flag is needed:
you can just "git add" the new name and "git rm" the old one,
with the same effect.

A flag for "git mv" would be convenient (and slightly more
efficient, not in terms of storage but in terms of CPU time
spent discovering that the contents under the new name
already exist in the object database). But Git will discover
the rename on its own in the usual way regardless of how
you get to that point.

Chris

Re: git mv after the fact

[Frieder Hannenheim]

In my particular use case I changed a patch to be a git patch with a
commit message and different filename so the move was not discovered
automatically. But I'm not sure if I staged the files so maybe it would
have been discovered.

Frieder

On 26.05.26 18:40, Chris Torek wrote:
> On Tue, May 26, 2026 at 6:18 AM Frieder Hannenheim <mail@fhannenheim.net> wrote:
>> I'd like to propose a new flag for git mv, that updates the index
>> like git mv normally would but does not move the file. ...
> You may already know this, but technically no flag is needed:
> you can just "git add" the new name and "git rm" the old one,
> with the same effect.
>
> A flag for "git mv" would be convenient (and slightly more
> efficient, not in terms of storage but in terms of CPU time
> spent discovering that the contents under the new name
> already exist in the object database). But Git will discover
> the rename on its own in the usual way regardless of how
> you get to that point.
>
> Chris

Re: git mv after the fact

[Ben Knoble]

> Le 26 mai 2026 à 12:46, Chris Torek <chris.torek@gmail.com> a écrit :
> 
> On Tue, May 26, 2026 at 6:18 AM Frieder Hannenheim <mail@fhannenheim.net> wrote:
>> I'd like to propose a new flag for git mv, that updates the index
>> like git mv normally would but does not move the file. ...
> 
> You may already know this, but technically no flag is needed:
> you can just "git add" the new name and "git rm" the old one,
> with the same effect.

Or indeed, « git add old new » should also work, I think.

> A flag for "git mv" would be convenient (and slightly more
> efficient, not in terms of storage but in terms of CPU time
> spent discovering that the contents under the new name
> already exist in the object database). But Git will discover
> the rename on its own in the usual way regardless of how
> you get to that point.
> 
> Chris

Re: git mv after the fact

[Junio C Hamano]

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

> On Tue, May 26, 2026 at 6:18 AM Frieder Hannenheim <mail@fhannenheim.net> wrote:
>> I'd like to propose a new flag for git mv, that updates the index
>> like git mv normally would but does not move the file. ...
>
> You may already know this, but technically no flag is needed:
> you can just "git add" the new name and "git rm" the old one,
> with the same effect.

Correct.

> A flag for "git mv" would be convenient (and slightly more
> efficient, not in terms of storage but in terms of CPU time
> spent discovering that the contents under the new name
> already exist in the object database).

May be convenient, but I do not get the "efficient" part.  Do you
mean that for two operations "add" and "rm", you need to spend two
index writes plus one file contents hash, as opposed to one index
rite without having to do any contents hash?

> But Git will discover
> the rename on its own in the usual way regardless of how
> you get to that point.

This is not incorrect per-se, but it is a confusing thing to say to
somebody who does not know the equivalence of "mv" and "rm + add".
It would not be clear to them that you are not talking about what
happens during "mv" or "rm + add", but about what happend during
"git log -M", "git diff -M", etc.

There is "git rm --cached" that can be used to recover from an
"oops, I removed the file from the filesystem without telling Git".

    $ date >new-file.txt
    $ git add new-file.txt
    $ rm new-file.txt
    $ git rm --cached new-file.txt

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

    $ date >old-file.txt
    $ git add old-file.txt
    $ mv old-file.txt new-file.txt
    $ git mv --cached old-file.txt new-file.txt

Thanks.

Re: git mv after the fact

[Chris Torek]

> 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

Re: git mv after the fact

[Tim Tassonis]

Yeah, and while we're at at it: why not another patch for

git rm 
file_i_deleted_but_didnt_tell_git_and_dont_want_an_error_message_because_thats_offensive

because that's always very rude, too, telling me to have to use

git rm -f

Because I also am very sensitive and don't like to be told I fucked up 
and have to be more specific about what I actually want. That's just 
toxic, man.




On 5/27/26 05:09, Junio C Hamano wrote:
> Chris Torek <chris.torek@gmail.com> writes:
> 
>> On Tue, May 26, 2026 at 6:18 AM Frieder Hannenheim <mail@fhannenheim.net> wrote:
>>> I'd like to propose a new flag for git mv, that updates the index
>>> like git mv normally would but does not move the file. ...
>>
>> You may already know this, but technically no flag is needed:
>> you can just "git add" the new name and "git rm" the old one,
>> with the same effect.
> 
> Correct.
> 
>> A flag for "git mv" would be convenient (and slightly more
>> efficient, not in terms of storage but in terms of CPU time
>> spent discovering that the contents under the new name
>> already exist in the object database).
> 
> May be convenient, but I do not get the "efficient" part.  Do you
> mean that for two operations "add" and "rm", you need to spend two
> index writes plus one file contents hash, as opposed to one index
> rite without having to do any contents hash?
> 
>> But Git will discover
>> the rename on its own in the usual way regardless of how
>> you get to that point.
> 
> This is not incorrect per-se, but it is a confusing thing to say to
> somebody who does not know the equivalence of "mv" and "rm + add".
> It would not be clear to them that you are not talking about what
> happens during "mv" or "rm + add", but about what happend during
> "git log -M", "git diff -M", etc.
> 
> There is "git rm --cached" that can be used to recover from an
> "oops, I removed the file from the filesystem without telling Git".
> 
>      $ date >new-file.txt
>      $ git add new-file.txt
>      $ rm new-file.txt
>      $ git rm --cached new-file.txt
> 
> 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".
> 
>      $ date >old-file.txt
>      $ git add old-file.txt
>      $ mv old-file.txt new-file.txt
>      $ git mv --cached old-file.txt new-file.txt
> 
> Thanks.
> 
> 

-- 
decentral.ch - IT Stuff
Tim Tassonis
Badenerstrasse 219
8003 Zürich
stuff@decentral.ch
+41 79 229 36 17

Re: git mv after the fact

[Junio C Hamano]

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.