{"thread":{"id":"63907","subject":"Feature Request: git mv --after (new flag)","startedAt":"2025-08-04T14:05:37Z","lastAt":"2025-08-06T05:17:56Z","messageCount":10,"participants":["FMorschel","Konstantin Khomoutov","Kristoffer Haugsbakk","Junio C Hamano","Johannes Sixt"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"523445","messageId":"2f505f75-112a-4b71-bb05-ea0cb7731cd7@fmorschel.dev","threadId":"63907","inReplyTo":"0afc01b2-11a2-4f77-a858-7a444e8bb1d4@fmorschel.dev","subject":"Feature Request: git mv --after (new flag)","fromName":"FMorschel","fromEmail":"git@fmorschel.dev","sentAt":"2025-08-04T14:05:32Z","receivedAt":"2025-08-04T14:05:37Z","isPatch":false,"sender":{"key":"git@fmorschel.dev","avatar":null},"body":"This is a request to add an –after mode to git mv command to explicitly \nmark a filesystem rename after it has occurred (analogous to mercurial \n=> hg mv –after).\n\nThis would allow IDE/Language refactor renames/moves and would make sure \ngit still detects the moves correctly for keeping the correct commit \nhistory.\n\nIf this has already been requested and I missed, please reply this with \nthe original request and consider this closed.\n\nIf anything else is required please let me know since this is my first \ninteraction with this tracker. Thank you for this incredible tool!\n\n​\n\n"},{"id":"523452","messageId":"hi7t3qk7difgzip7syscarnf5ui5avnhmjxil4vzurwcfo7a6x@drccf7gibn72","threadId":"63907","inReplyTo":"2f505f75-112a-4b71-bb05-ea0cb7731cd7@fmorschel.dev","subject":"Re: Feature Request: git mv --after (new flag)","fromName":"Konstantin Khomoutov","fromEmail":"kostix@bswap.ru","sentAt":"2025-08-04T15:02:43Z","receivedAt":"2025-08-04T15:18:04Z","isPatch":false,"sender":{"key":"kostix@bswap.ru","avatar":null},"body":"On Mon, Aug 04, 2025 at 02:05:32PM +0000, FMorschel wrote:\n\n> This is a request to add an –after mode to git mv command to explicitly \n> mark a filesystem rename after it has occurred (analogous to mercurial \n> => hg mv –after).\n> \n> This would allow IDE/Language refactor renames/moves and would make sure \n> git still detects the moves correctly for keeping the correct commit \n> history.\n\nGit does not track renames in the commits in creates, so, basically, if you\nhave a file foo.txt under the Git's control, and do\n\n $ git mv foo.txt bar.txt\n $ git commit\n\nThe recorded commit will reference a tree object which will - compared\nto the tree object of the preceding commit - have an entry for bar.txt\nand not have an entry for foo.txt.\n\nHence a command like \"git mv --after\", if implemented, would be a pure\nsyntactic sugar for \"git rm && git add \".\n\n"},{"id":"523456","messageId":"917aa62f-5f2a-40d7-8fa5-f19a14926241@fmorschel.dev","threadId":"63907","inReplyTo":"hi7t3qk7difgzip7syscarnf5ui5avnhmjxil4vzurwcfo7a6x@drccf7gibn72","subject":"Re: Feature Request: git mv --after (new flag)","fromName":"FMorschel","fromEmail":"git@fmorschel.dev","sentAt":"2025-08-04T15:53:03Z","receivedAt":"2025-08-04T15:53:08Z","isPatch":false,"sender":{"key":"git@fmorschel.dev","avatar":null},"body":"Wow, this seems to me a really weird design choice.\n\nDo you have any insight on to why is this?\n\nAnd do you have any idea if this behaviour is tracked to change \nsomewhere? Maybe by project config? Like, one project could opt-in for \nan actual \"rename\" history.\n\nOn 04/08/2025 12:02, Konstantin Khomoutov wrote:\n> On Mon, Aug 04, 2025 at 02:05:32PM +0000, FMorschel wrote:\n>\n>> This is a request to add an –after mode to git mv command to explicitly\n>> mark a filesystem rename after it has occurred (analogous to mercurial\n>> => hg mv –after).\n>>\n>> This would allow IDE/Language refactor renames/moves and would make sure\n>> git still detects the moves correctly for keeping the correct commit\n>> history.\n> Git does not track renames in the commits in creates, so, basically, if you\n> have a file foo.txt under the Git's control, and do\n>\n> $ git mv foo.txt bar.txt\n> $ git commit\n>\n> The recorded commit will reference a tree object which will - compared\n> to the tree object of the preceding commit - have an entry for bar.txt\n> and not have an entry for foo.txt.\n>\n> Hence a command like \"git mv --after\", if implemented, would be a pure\n> syntactic sugar for \"git rm && git add \".\n>\n\n"},{"id":"523458","messageId":"ddc841ec-bc4b-4c01-a99e-9a65af3963bc@app.fastmail.com","threadId":"63907","inReplyTo":"917aa62f-5f2a-40d7-8fa5-f19a14926241@fmorschel.dev","subject":"Re: Feature Request: git mv --after (new flag)","fromName":"Kristoffer Haugsbakk","fromEmail":"kristofferhaugsbakk@fastmail.com","sentAt":"2025-08-04T16:04:05Z","receivedAt":"2025-08-04T16:04:37Z","isPatch":false,"sender":{"key":"kristofferhaugsbakk@fastmail.com","avatar":null},"body":"On Mon, Aug 4, 2025, at 17:53, FMorschel wrote:\n> Wow, this seems to me a really weird design choice.\n>\n> Do you have any insight on to why is this?\n\nhttps://lore.kernel.org/git/Pine.LNX.4.58.0504150753440.7211@ppc970.osdl.org/\n\n> And do you have any idea if this behaviour is tracked to change \n> somewhere? Maybe by project config? Like, one project could opt-in for \n> an actual \"rename\" history.\n\nAs a bystander: I’ve never seen anyone involved in this project\nwanting to track renames as part of the commit.\n\nPS: You need to keep the CC intact when replying on this list. :)\n"},{"id":"523459","messageId":"xmqqwm7j59vv.fsf@gitster.g","threadId":"63907","inReplyTo":"ddc841ec-bc4b-4c01-a99e-9a65af3963bc@app.fastmail.com","subject":"Re: Feature Request: git mv --after (new flag)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-08-04T16:28:36Z","receivedAt":"2025-08-04T16:28:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Kristoffer Haugsbakk\" writes:\n\n> On Mon, Aug 4, 2025, at 17:53, FMorschel wrote:\n>> Wow, this seems to me a really weird design choice.\n>>\n>> Do you have any insight on to why is this?\n>\n> https://lore.kernel.org/git/Pine.LNX.4.58.0504150753440.7211@ppc970.osdl.org/\n\nThanks for giving this URL so that I do not have to ;-)\n\n>\n>> And do you have any idea if this behaviour is tracked to change \n>> somewhere? Maybe by project config? Like, one project could opt-in for \n>> an actual \"rename\" history.\n>\n> As a bystander: I’ve never seen anyone involved in this project\n> wanting to track renames as part of the commit.\n>\n> PS: You need to keep the CC intact when replying on this list. :)\n"},{"id":"523511","messageId":"4d08a37e-2c12-4e3b-b6a6-028e2d6c0a22@kdbg.org","threadId":"63907","inReplyTo":"2f505f75-112a-4b71-bb05-ea0cb7731cd7@fmorschel.dev","subject":"Re: Feature Request: git mv --after (new flag)","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2025-08-05T06:03:46Z","receivedAt":"2025-08-05T06:03:50Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 04.08.25 um 16:05 schrieb FMorschel:\n> This is a request to add an –after mode to git mv command to explicitly \n> mark a filesystem rename after it has occurred (analogous to mercurial \n> => hg mv –after).\n> \n> This would allow IDE/Language refactor renames/moves and would make sure \n> git still detects the moves correctly for keeping the correct commit \n> history.\nI've wished for this feature several times already. Though, in Git\nparlance it would be spelled `git mv --cached`.\n\n-- Hannes\n\n"},{"id":"523528","messageId":"d7ey5l2bcy4xzidqyq5by4mrwgziahypvnco5ilbik4y3feqhj@vspbafxowl5l","threadId":"63907","inReplyTo":"ddc841ec-bc4b-4c01-a99e-9a65af3963bc@app.fastmail.com","subject":"Re: Feature Request: git mv --after (new flag)","fromName":"Konstantin Khomoutov","fromEmail":"kostix@bswap.ru","sentAt":"2025-08-05T09:36:46Z","receivedAt":"2025-08-05T09:52:05Z","isPatch":false,"sender":{"key":"kostix@bswap.ru","avatar":null},"body":"On Mon, Aug 04, 2025 at 06:04:05PM +0200, Kristoffer Haugsbakk wrote:\n\n[...]\n>> Wow, this seems to me a really weird design choice.\n>>\n>> Do you have any insight on to why is this?\n> \n> https://lore.kernel.org/git/Pine.LNX.4.58.0504150753440.7211@ppc970.osdl.org/\n\nFMorschel, when reading, consider paying close attention to the two things:\n\n - What Linus says about much of the code coming in in the form of the\n textual patches mailed to the various mailing lists.\n\n - An example describing a commit which has unified 5 different code snippets\n into one.\n\nBasically, these bits highlight the fact that files, albeit useful and\nubiquitous on today's commodity operating systems, frame our way of thinking\nof how information is tracked a bit too much ;-)\n\n"},{"id":"523530","messageId":"09e2fb55-2f04-44db-a062-fa6c2c01c8eb@fmorschel.dev","threadId":"63907","inReplyTo":"d7ey5l2bcy4xzidqyq5by4mrwgziahypvnco5ilbik4y3feqhj@vspbafxowl5l","subject":"Re: Feature Request: git mv --after (new flag)","fromName":"FMorschel","fromEmail":"git@fmorschel.dev","sentAt":"2025-08-05T11:47:31Z","receivedAt":"2025-08-05T11:47:51Z","isPatch":false,"sender":{"key":"git@fmorschel.dev","avatar":null},"body":"> On 05/08/2025 06:36, Konstantin Khomoutov wrote:\n>> FMorschel, when reading, consider paying close attention to the two things:\n>>\n>> - What Linus says about much of the code coming in in the form of the\n>> textual patches mailed to the various mailing lists.\n>\n>\n> I see that now, thanks for the link and for pointing it out.\n>\n>> - An example describing a commit which has unified 5 different code snippets\n>> into one.\n>>\n>> Basically, these bits highlight the fact that files, albeit useful and\n>> ubiquitous on today's commodity operating systems, frame our way of thinking\n>> of how information is tracked a bit too much ;-)\n>\n> I never had thought of that.\n>\n> My only push-back against this decision would be to allow the \n> developer (that actually _understands_ the changes) the ability to \n> make the decision of tracking that.\n>\n> But since the decision (of what is related to what) is that this \n> should mainly be handled by the threshold (so git can figure it out \n> for you) it's fine then.\n>\n> Thank you all for taking the time to answer me!\n>\n\n"},{"id":"523564","messageId":"xmqqh5yl3hdj.fsf@gitster.g","threadId":"63907","inReplyTo":"4d08a37e-2c12-4e3b-b6a6-028e2d6c0a22@kdbg.org","subject":"Re: Feature Request: git mv --after (new flag)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-08-05T15:42:00Z","receivedAt":"2025-08-05T15:42:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Sixt writes:\n\n> Am 04.08.25 um 16:05 schrieb FMorschel:\n>> This is a request to add an –after mode to git mv command to explicitly \n>> mark a filesystem rename after it has occurred (analogous to mercurial \n>> => hg mv –after).\n>> \n>> This would allow IDE/Language refactor renames/moves and would make sure \n>> git still detects the moves correctly for keeping the correct commit \n>> history.\n>\n> I've wished for this feature several times already. Though, in Git\n> parlance it would be spelled `git mv --cached`.\n\nI couldn't really tell if the request was to make \"git mv --after\",\nwithout any other argument after it, do something sensible. \n\nE.g. after the end-user did \"mv A B\", figure out from the paths\nthat are apparently removed from the working tree relative to what\nis recorded in the index (like A, but there may be others), and the\npaths that have not been made to known by Git (like B, but there may\nbe others), and infer what happened, and \"git mv --cached A B\" for\nthem.\n\nI do not think we have that \"match the missing paths and untracked\npaths to figure out\" part. It may be trivial if you are willing to\nmake a stupid version that takes all the untracked paths by trusting\nthey maintain good .gitignore (it would roughly be \"git add .\"), but\neven if you try to do a much better job and actually avoid adding\npaths that are not involved in this \"mv\", it should not be rocket\nscience to do so.\n\nBut if that is not needed, then we can declare that we already have\nit and move on? I dunno.\n\n"},{"id":"523620","messageId":"xmqq34a5xc3j.fsf@gitster.g","threadId":"63907","inReplyTo":"09e2fb55-2f04-44db-a062-fa6c2c01c8eb@fmorschel.dev","subject":"Re: Feature Request: git mv --after (new flag)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-08-06T05:17:52Z","receivedAt":"2025-08-06T05:17:56Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"FMorschel writes:\n\n>> But since the decision (of what is related to what) is that this \n>> should mainly be handled by the threshold (so git can figure it out \n>> for you) it's fine then.\n\nThe main idea behind the design is that Git can _afford_ to spend\nmore work at the time of investigating (e.g. when the user asks to\nfind where this single function came from and the tool answers that\nit is the result of consolidating five duplicated functions) than\nthe time of recording commits (i.e. when it is not yet known what\nquestions the users will ask about the commit in the future), and\nthat Git can _improve_ over time how it figures out which removed\nones correspond to which added ones when it is asked to find out\nmoves and copies, exactly because we do not force people to record\nmoves at the time of the commit.\n\nIt does not preclude a new feature to allow you to tell, say, \"git\nblame\", an extra piece of information to help the command you run,\nlike, \"hey, Git, you may not realize it with the current heuristics\nyou have, but at commit X, lines N to M of path G was copied to\nlines L to K of path F. You can take that into account when you\nfigure out where the lines of the current file at path F came from\".\n\nYou may even store that piece of information alongside commits in a\nform that can be transferred across repositories, like notes. The\nimportant point is to keep such auxiliary pieces of information\noutside the commit object, yet allow us to look it up for each\ncommit.\n"}]}