Re: Feature Request: git mv --after (new flag)

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 5, 2025, 15:42 UTC
Message-ID: <xmqqh5yl3hdj.fsf@gitster.g>
In-Reply-To: <4d08a37e-2c12-4e3b-b6a6-028e2d6c0a22@kdbg.org>

Johannes Sixt <j6t@kdbg.org> writes:

Show 11 quoted lines

> Am 04.08.25 um 16:05 schrieb FMorschel:
>> This is a request to add an –after mode to git mv command to explicitly 
>> mark a filesystem rename after it has occurred (analogous to mercurial 
>> => hg mv –after).
>> 
>> This would allow IDE/Language refactor renames/moves and would make sure 
>> git still detects the moves correctly for keeping the correct commit 
>> history.
>
> I've wished for this feature several times already. Though, in Git
> parlance it would be spelled `git mv --cached`.

I couldn't really tell if the request was to make "git mv --after", without any other argument after it, do something sensible.

E.g. after the end-user did "mv A B", figure out from the paths that are apparently removed from the working tree relative to what is recorded in the index (like A, but there may be others), and the paths that have not been made to known by Git (like B, but there may be others), and infer what happened, and "git mv --cached A B" for them.

I do not think we have that "match the missing paths and untracked paths to figure out" part. It may be trivial if you are willing to make a stupid version that takes all the untracked paths by trusting they maintain good .gitignore (it would roughly be "git add ."), but even if you try to do a much better job and actually avoid adding paths that are not involved in this "mv", it should not be rocket science to do so.

But if that is not needed, then we can declare that we already have it and move on? I dunno.