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

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

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

If this has already been requested and I missed, please reply this with 
the original request and consider this closed.

If anything else is required please let me know since this is my first 
interaction with this tracker. Thank you for this incredible tool!

​

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

[Konstantin Khomoutov]

On Mon, Aug 04, 2025 at 02:05:32PM +0000, FMorschel wrote:

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

Git does not track renames in the commits in creates, so, basically, if you
have a file foo.txt under the Git's control, and do

  $ git mv foo.txt bar.txt
  $ git commit

The recorded commit will reference a tree object which will - compared
to the tree object of the preceding commit - have an entry for bar.txt
and not have an entry for foo.txt.

Hence a command like "git mv --after", if implemented, would be a pure
syntactic sugar for "git rm <old_name> && git add <new_name>".

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

[FMorschel]

Wow, this seems to me a really weird design choice.

Do you have any insight on to why is this?

And do you have any idea if this behaviour is tracked to change 
somewhere? Maybe by project config? Like, one project could opt-in for 
an actual "rename" history.

On 04/08/2025 12:02, Konstantin Khomoutov wrote:
> On Mon, Aug 04, 2025 at 02:05:32PM +0000, FMorschel wrote:
>
>> 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.
> Git does not track renames in the commits in creates, so, basically, if you
> have a file foo.txt under the Git's control, and do
>
>    $ git mv foo.txt bar.txt
>    $ git commit
>
> The recorded commit will reference a tree object which will - compared
> to the tree object of the preceding commit - have an entry for bar.txt
> and not have an entry for foo.txt.
>
> Hence a command like "git mv --after", if implemented, would be a pure
> syntactic sugar for "git rm <old_name> && git add <new_name>".
>

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

[Kristoffer Haugsbakk]

On Mon, Aug 4, 2025, at 17:53, FMorschel wrote:
> Wow, this seems to me a really weird design choice.
>
> Do you have any insight on to why is this?

https://lore.kernel.org/git/Pine.LNX.4.58.0504150753440.7211@ppc970.osdl.org/

> And do you have any idea if this behaviour is tracked to change 
> somewhere? Maybe by project config? Like, one project could opt-in for 
> an actual "rename" history.

As a bystander: I’ve never seen anyone involved in this project
wanting to track renames as part of the commit.

PS: You need to keep the CC intact when replying on this list. :)

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

[Junio C Hamano]

"Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com> writes:

> On Mon, Aug 4, 2025, at 17:53, FMorschel wrote:
>> Wow, this seems to me a really weird design choice.
>>
>> Do you have any insight on to why is this?
>
> https://lore.kernel.org/git/Pine.LNX.4.58.0504150753440.7211@ppc970.osdl.org/

Thanks for giving this URL so that I do not have to ;-)

>
>> And do you have any idea if this behaviour is tracked to change 
>> somewhere? Maybe by project config? Like, one project could opt-in for 
>> an actual "rename" history.
>
> As a bystander: I’ve never seen anyone involved in this project
> wanting to track renames as part of the commit.
>
> PS: You need to keep the CC intact when replying on this list. :)

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

[Johannes Sixt]

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

-- Hannes

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

[Konstantin Khomoutov]

On Mon, Aug 04, 2025 at 06:04:05PM +0200, Kristoffer Haugsbakk wrote:

[...]
>> Wow, this seems to me a really weird design choice.
>>
>> Do you have any insight on to why is this?
> 
> https://lore.kernel.org/git/Pine.LNX.4.58.0504150753440.7211@ppc970.osdl.org/

FMorschel, when reading, consider paying close attention to the two things:

 - What Linus says about much of the code coming in in the form of the
   textual patches mailed to the various mailing lists.

 - An example describing a commit which has unified 5 different code snippets
   into one.

Basically, these bits highlight the fact that files, albeit useful and
ubiquitous on today's commodity operating systems, frame our way of thinking
of how information is tracked a bit too much ;-)

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

[FMorschel]

> On 05/08/2025 06:36, Konstantin Khomoutov wrote:
>> FMorschel, when reading, consider paying close attention to the two things:
>>
>>   - What Linus says about much of the code coming in in the form of the
>>     textual patches mailed to the various mailing lists.
>
>
> I see that now, thanks for the link and for pointing it out.
>
>>   - An example describing a commit which has unified 5 different code snippets
>>     into one.
>>
>> Basically, these bits highlight the fact that files, albeit useful and
>> ubiquitous on today's commodity operating systems, frame our way of thinking
>> of how information is tracked a bit too much ;-)
>
> I never had thought of that.
>
> My only push-back against this decision would be to allow the 
> developer (that actually _understands_ the changes) the ability to 
> make the decision of tracking that.
>
> But since the decision (of what is related to what) is that this 
> should mainly be handled by the threshold (so git can figure it out 
> for you) it's fine then.
>
> Thank you all for taking the time to answer me!
>

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

[Junio C Hamano]

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.

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

[Junio C Hamano]

FMorschel <git@fmorschel.dev> writes:

>> But since the decision (of what is related to what) is that this 
>> should mainly be handled by the threshold (so git can figure it out 
>> for you) it's fine then.

The main idea behind the design is that Git can _afford_ to spend
more work at the time of investigating (e.g. when the user asks to
find where this single function came from and the tool answers that
it is the result of consolidating five duplicated functions) than
the time of recording commits (i.e. when it is not yet known what
questions the users will ask about the commit in the future), and
that Git can _improve_ over time how it figures out which removed
ones correspond to which added ones when it is asked to find out
moves and copies, exactly because we do not force people to record
moves at the time of the commit.

It does not preclude a new feature to allow you to tell, say, "git
blame", an extra piece of information to help the command you run,
like, "hey, Git, you may not realize it with the current heuristics
you have, but at commit X, lines N to M of path G was copied to
lines L to K of path F.  You can take that into account when you
figure out where the lines of the current file at path F came from".

You may even store that piece of information alongside commits in a
form that can be transferred across repositories, like notes.  The
important point is to keep such auxiliary pieces of information
outside the commit object, yet allow us to look it up for each
commit.