From: Tim Tassonis <stuff@decentral•ch>
To: Junio C Hamano <gitster@pobox•com>, Chris Torek <chris.torek@gmail•com>
Cc: Frieder Hannenheim <mail@fhannenheim•net>, git@vger•kernel.org
Subject: Re: git mv after the fact
Date: Wed, 27 May 2026 05:27:14 +0200 [thread overview]
Message-ID: <983b4ba0-d2b0-4d29-aabe-9e7b3987d514@decentral.ch> (raw)
In-Reply-To: <xmqqy0h5lfa0.fsf@gitster.g>
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
prev parent reply other threads:[~2026-05-27 4:00 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-26 12:57 git mv after the fact Frieder Hannenheim
2026-05-26 16:40 ` Chris Torek
2026-05-26 16:50 ` Frieder Hannenheim
2026-05-26 21:29 ` Ben Knoble
2026-05-27 3:09 ` Junio C Hamano
2026-05-27 3:19 ` Chris Torek
2026-05-27 23:22 ` Junio C Hamano
2026-05-28 14:28 ` Ben Knoble
2026-05-28 20:36 ` Junio C Hamano
2026-05-27 3:27 ` Tim Tassonis [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=983b4ba0-d2b0-4d29-aabe-9e7b3987d514@decentral.ch \
--to=stuff@decentral$(echo .)ch \
--cc=chris.torek@gmail$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
--cc=mail@fhannenheim$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox