{"thread":{"id":"38658","subject":"weird behaviour in git","startedAt":"2015-02-26T14:12:34Z","lastAt":"2015-02-26T15:54:30Z","messageCount":5,"participants":["Thomas Klausner","Michael J Gruber","David Kastrup"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"256689","messageId":"20150226141234.GP19896@danbala.tuwien.ac.at","threadId":"38658","inReplyTo":null,"subject":"weird behaviour in git","fromName":"Thomas Klausner","fromEmail":"tk@giga.or.at","sentAt":"2015-02-26T14:12:34Z","receivedAt":"2015-02-26T14:12:34Z","isPatch":false,"sender":{"key":"tk@giga.or.at","avatar":null},"body":"Hi!\n\nI've played around with git and found that 'git mv' does not honor\nwhat I tell it to do:\n\nwiz@yt:~> mkdir a\nwiz@yt:~> cd a\nwiz@yt:~/a> git init .\nInitialized empty Git repository in /home/wiz/a/.git/\nwiz@yt:~/a> touch a\nwiz@yt:~/a> git add a\nwiz@yt:~/a> git commit -m 'add a'\n[master (root-commit) 99d0ee7] add a\n 1 file changed, 0 insertions(+), 0 deletions(-)\n create mode 100644 a\nwiz@yt:~/a> git mv a b\nwiz@yt:~/a> touch Makefile\nwiz@yt:~/a> git add Makefile\nwiz@yt:~/a> git commit\n\n\n# Please enter the commit message for your changes. Lines starting\n# with '#' will be ignored, and an empty message aborts the commit.\n# On branch master\n# Changes to be committed:\n#       renamed:    a -> Makefile\n#       new file:   b\n#\n\nThis is reproducible for me with \"git version 2.3.0\" on\nNetBSD-7.99.5/amd64.\n\nI guess this happens because the checksums of the files are the same\nand 'Makefile' is earlier when sorting, but since I explicitly told\n\"git mv\" old and new name, I think that's a bug nevertheless.\n Thomas\n"},{"id":"256691","messageId":"54EF3179.8030104@drmicha.warpmail.net","threadId":"38658","inReplyTo":"20150226141234.GP19896@danbala.tuwien.ac.at","subject":"Re: weird behaviour in git","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2015-02-26T14:45:13Z","receivedAt":"2015-02-26T14:45:13Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Thomas Klausner venit, vidit, dixit 26.02.2015 15:12:\n> Hi!\n> \n> I've played around with git and found that 'git mv' does not honor\n> what I tell it to do:\n> \n> wiz@yt:~> mkdir a\n> wiz@yt:~> cd a\n> wiz@yt:~/a> git init .\n> Initialized empty Git repository in /home/wiz/a/.git/\n> wiz@yt:~/a> touch a\n> wiz@yt:~/a> git add a\n> wiz@yt:~/a> git commit -m 'add a'\n> [master (root-commit) 99d0ee7] add a\n>  1 file changed, 0 insertions(+), 0 deletions(-)\n>  create mode 100644 a\n> wiz@yt:~/a> git mv a b\n> wiz@yt:~/a> touch Makefile\n> wiz@yt:~/a> git add Makefile\n> wiz@yt:~/a> git commit\n> \n> \n> # Please enter the commit message for your changes. Lines starting\n> # with '#' will be ignored, and an empty message aborts the commit.\n> # On branch master\n> # Changes to be committed:\n> #       renamed:    a -> Makefile\n> #       new file:   b\n> #\n> \n> This is reproducible for me with \"git version 2.3.0\" on\n> NetBSD-7.99.5/amd64.\n> \n> I guess this happens because the checksums of the files are the same\n> and 'Makefile' is earlier when sorting, but since I explicitly told\n> \"git mv\" old and new name, I think that's a bug nevertheless.\n>  Thomas\n> \n\ngit tracks content, not paths.\n\nIt does record the path at which the tracked content is, of course. But\nit tracks the history of content, not that of paths.\n\nWhat you see in the diff above is merely one way to interpret the\nhistory of the content. Saying\n\nrenamed:  a -> b\nnew file: Makefile\n\nleads to the same content at the same paths (with the proper new file\ncontent).\n\nBy default, diff tries to interpret content history in terms of renames\nand copies when possible, in order to help users. Sometimes this fails -\nwhile still being correct, it confuses them ;)\n\nMichael\n"},{"id":"256692","messageId":"20150226145848.GQ19896@danbala.tuwien.ac.at","threadId":"38658","inReplyTo":"54EF3179.8030104@drmicha.warpmail.net","subject":"Re: weird behaviour in git","fromName":"Thomas Klausner","fromEmail":"tk@giga.or.at","sentAt":"2015-02-26T14:58:48Z","receivedAt":"2015-02-26T14:58:48Z","isPatch":false,"sender":{"key":"tk@giga.or.at","avatar":null},"body":"On Thu, Feb 26, 2015 at 03:45:13PM +0100, Michael J Gruber wrote:\n> Thomas Klausner venit, vidit, dixit 26.02.2015 15:12:\n> > Hi!\n> > \n> > I've played around with git and found that 'git mv' does not honor\n> > what I tell it to do:\n> > \n> > wiz@yt:~> mkdir a\n> > wiz@yt:~> cd a\n> > wiz@yt:~/a> git init .\n> > Initialized empty Git repository in /home/wiz/a/.git/\n> > wiz@yt:~/a> touch a\n> > wiz@yt:~/a> git add a\n> > wiz@yt:~/a> git commit -m 'add a'\n> > [master (root-commit) 99d0ee7] add a\n> >  1 file changed, 0 insertions(+), 0 deletions(-)\n> >  create mode 100644 a\n> > wiz@yt:~/a> git mv a b\n> > wiz@yt:~/a> touch Makefile\n> > wiz@yt:~/a> git add Makefile\n> > wiz@yt:~/a> git commit\n> > \n> > \n> > # Please enter the commit message for your changes. Lines starting\n> > # with '#' will be ignored, and an empty message aborts the commit.\n> > # On branch master\n> > # Changes to be committed:\n> > #       renamed:    a -> Makefile\n> > #       new file:   b\n> > #\n> > \n> > This is reproducible for me with \"git version 2.3.0\" on\n> > NetBSD-7.99.5/amd64.\n> > \n> > I guess this happens because the checksums of the files are the same\n> > and 'Makefile' is earlier when sorting, but since I explicitly told\n> > \"git mv\" old and new name, I think that's a bug nevertheless.\n> >  Thomas\n> > \n> \n> git tracks content, not paths.\n> \n> It does record the path at which the tracked content is, of course. But\n> it tracks the history of content, not that of paths.\n> \n> What you see in the diff above is merely one way to interpret the\n> history of the content. Saying\n> \n> renamed:  a -> b\n> new file: Makefile\n> \n> leads to the same content at the same paths (with the proper new file\n> content).\n> \n> By default, diff tries to interpret content history in terms of renames\n> and copies when possible, in order to help users. Sometimes this fails -\n> while still being correct, it confuses them ;)\n\nSure, that's one way to look at it, but I disagree. You give the user\nthe way to tell the system the intention of which file moves where,\nbut internally this information is lost and \"guessed\" incorrectly.\n\nhg seems to do this correctly, the same commands with 'hg diff --git'\nat the end show:\n\ndiff --git a/Makefile b/Makefile\nnew file mode 100644\ndiff --git a/a b/b\nrename from a\nrename to b\n\n Thomas\n"},{"id":"256694","messageId":"54EF3A38.4090708@drmicha.warpmail.net","threadId":"38658","inReplyTo":"20150226145848.GQ19896@danbala.tuwien.ac.at","subject":"Re: weird behaviour in git","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2015-02-26T15:22:32Z","receivedAt":"2015-02-26T15:22:32Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Thomas Klausner venit, vidit, dixit 26.02.2015 15:58:\n> On Thu, Feb 26, 2015 at 03:45:13PM +0100, Michael J Gruber wrote:\n>> Thomas Klausner venit, vidit, dixit 26.02.2015 15:12:\n>>> Hi!\n>>>\n>>> I've played around with git and found that 'git mv' does not honor\n>>> what I tell it to do:\n>>>\n>>> wiz@yt:~> mkdir a\n>>> wiz@yt:~> cd a\n>>> wiz@yt:~/a> git init .\n>>> Initialized empty Git repository in /home/wiz/a/.git/\n>>> wiz@yt:~/a> touch a\n>>> wiz@yt:~/a> git add a\n>>> wiz@yt:~/a> git commit -m 'add a'\n>>> [master (root-commit) 99d0ee7] add a\n>>>  1 file changed, 0 insertions(+), 0 deletions(-)\n>>>  create mode 100644 a\n>>> wiz@yt:~/a> git mv a b\n>>> wiz@yt:~/a> touch Makefile\n>>> wiz@yt:~/a> git add Makefile\n>>> wiz@yt:~/a> git commit\n>>>\n>>>\n>>> # Please enter the commit message for your changes. Lines starting\n>>> # with '#' will be ignored, and an empty message aborts the commit.\n>>> # On branch master\n>>> # Changes to be committed:\n>>> #       renamed:    a -> Makefile\n>>> #       new file:   b\n>>> #\n>>>\n>>> This is reproducible for me with \"git version 2.3.0\" on\n>>> NetBSD-7.99.5/amd64.\n>>>\n>>> I guess this happens because the checksums of the files are the same\n>>> and 'Makefile' is earlier when sorting, but since I explicitly told\n>>> \"git mv\" old and new name, I think that's a bug nevertheless.\n>>>  Thomas\n>>>\n>>\n>> git tracks content, not paths.\n>>\n>> It does record the path at which the tracked content is, of course. But\n>> it tracks the history of content, not that of paths.\n>>\n>> What you see in the diff above is merely one way to interpret the\n>> history of the content. Saying\n>>\n>> renamed:  a -> b\n>> new file: Makefile\n>>\n>> leads to the same content at the same paths (with the proper new file\n>> content).\n>>\n>> By default, diff tries to interpret content history in terms of renames\n>> and copies when possible, in order to help users. Sometimes this fails -\n>> while still being correct, it confuses them ;)\n> \n> Sure, that's one way to look at it, but I disagree. You give the user\n> the way to tell the system the intention of which file moves where,\n> but internally this information is lost and \"guessed\" incorrectly.\n> \n> hg seems to do this correctly, the same commands with 'hg diff --git'\n> at the end show:\n> \n> diff --git a/Makefile b/Makefile\n> new file mode 100644\n> diff --git a/a b/b\n> rename from a\n> rename to b\n> \n>  Thomas\n> \n\nMaybe you can re-read what I wrote above, keeping in mind the first line:\n\ngit tracks content, not paths.\n\nThat explains everything, really.\n\nMichael\n"},{"id":"256695","messageId":"87sidsbrd5.fsf@fencepost.gnu.org","threadId":"38658","inReplyTo":"20150226141234.GP19896@danbala.tuwien.ac.at","subject":"Re: weird behaviour in git","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2015-02-26T15:54:30Z","receivedAt":"2015-02-26T15:54:30Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Thomas Klausner <tk@giga.or.at> writes:\n\n> I've played around with git and found that 'git mv' does not honor\n> what I tell it to do:\n>\n> wiz@yt:~> mkdir a\n> wiz@yt:~> cd a\n> wiz@yt:~/a> git init .\n> Initialized empty Git repository in /home/wiz/a/.git/\n> wiz@yt:~/a> touch a\n> wiz@yt:~/a> git add a\n> wiz@yt:~/a> git commit -m 'add a'\n> [master (root-commit) 99d0ee7] add a\n>  1 file changed, 0 insertions(+), 0 deletions(-)\n>  create mode 100644 a\n> wiz@yt:~/a> git mv a b\n> wiz@yt:~/a> touch Makefile\n> wiz@yt:~/a> git add Makefile\n> wiz@yt:~/a> git commit\n>\n>\n> # Please enter the commit message for your changes. Lines starting\n> # with '#' will be ignored, and an empty message aborts the commit.\n> # On branch master\n> # Changes to be committed:\n> #       renamed:    a -> Makefile\n> #       new file:   b\n> #\n\ngit mv was tasked with removing file a and creating file b with the same\ncontent and permissions.  It did so successfully.\n\n\"Changes to be committed\" states an interpretation consistent with that.\n\nNow it is entirely silly in my book to describe files as \"renamed\" that\nare actually empty and thus do not contain a single common byte.\nI would call that change description a bug or at least a \"misfeature\".\n\ngit mv, however, did exactly what it was tasked to do and could not\npossibly do anything better since Git does, by design, not ever track\nfile operations.\n\n> This is reproducible for me with \"git version 2.3.0\" on\n> NetBSD-7.99.5/amd64.\n>\n> I guess this happens because the checksums of the files are the same\n> and 'Makefile' is earlier when sorting, but since I explicitly told\n> \"git mv\" old and new name, I think that's a bug nevertheless.\n\nNo.  Git mv is just a convenience command for deleting one file and\ncreating another one with the same contents.  Git has no concept of file\nrenames in its repository, so git mv cannot record anything there that\ncould not be interpreted exactly like the commit info interpreted it.\n\nIt's nonsensical and should in my opinion rather be stated as\n\n# Changes to be committed:\n#       removed:    a\n#       new file:   Makefile\n#       new file:   b\n\nBut that's not the fault of Git mv.\n\n-- \nDavid Kastrup\n"}]}