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

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

Johannes Sixt <j6t@kdbg.org> writes:

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