{"thread":{"id":"22961","subject":"Cherry-pick with symlinks fails horribly","startedAt":"2010-03-09T01:28:30Z","lastAt":"2010-03-25T05:01:44Z","messageCount":7,"participants":["Alexander Gladysh","Christian Couder","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"136436","messageId":"c6c947f61003081728u48292de4x6f2c26e1ea9c1756@mail.gmail.com","threadId":"22961","inReplyTo":null,"subject":"Cherry-pick with symlinks fails horribly","fromName":"Alexander Gladysh","fromEmail":"agladysh@gmail.com","sentAt":"2010-03-09T01:28:30Z","receivedAt":"2010-03-09T01:28:30Z","isPatch":false,"sender":{"key":"agladysh@gmail.com","avatar":"https://avatars.githubusercontent.com/u/38239?v=4"},"body":"Hi, list!\n\nOS X 10.6.2\nGit 1.7.0.2\n\nI'm complaining about Git symlink handling again. This time it is cherry-pick.\n\nIn my repo I have a symlink pointing to a directory.\n\nI swap symlink with the directory in a single commit.\n\nNow, if I try to cherry-pick any later commit from the branch that has\nthat swap commit to a branch that have not, cherry-pick fails\nhorribly.\n\nSee script to reproduce the bug below (run it in a clean directory).\n\nOutput example:\n\n$ git cherry-pick \n\nAutomatic cherry-pick failed. After resolving the conflicts,\nmark the corrected paths with 'git add ' or 'git rm '\nand commit the result with:\n\n git commit -c 6a398597ce7a00fe05f43ff88808303eb151dfb5\n\n$ git status # Note the \"Untracked files\" section\n\n# On branch master\n# Changes to be committed:\n# (use \"git reset HEAD ...\" to unstage)\n#\n#\trenamed: a/f -> f1\n#\n# Unmerged paths:\n# (use \"git reset HEAD ...\" to unstage)\n# (use \"git add/rm ...\" as appropriate to mark resolution)\n#\n#\tadded by us: b/a\n#\n# Untracked files:\n# (use \"git add ...\" to include in what will be committed)\n#\n#\tb/a~HEAD\n\n(Also I've seen git reset --hard to fail afterwards, complaining it\ncan't delete a directory, but I can't reproduce it now.)\n\nI see a similar behaviour if I try to do interactive rebase accross\nsymlink swap commit.\n\nAlexander.\n\n#! /bin/bash\n\ngit init\n\nmkdir a\ntouch a/f\ngit add a\ngit commit -m \"a\"\n\nmkdir b\nln -s ../a b/a\ngit add b\ngit commit -m \"b\"\n\ngit checkout -b branch\nrm b/a\nmv a b/\nln -s b/a a\ngit add .\ngit commit -m \"swap\"\n\ntouch f1\ngit add f1\ngit commit -m \"f1\"\n\ngit checkout master\n\ngit cherry-pick `git rev-parse branch` # This one breaks horribly\n"},{"id":"136534","messageId":"c6c947f61003101054j514d8d19g5810deb124ac2106@mail.gmail.com","threadId":"22961","inReplyTo":"c6c947f61003081728u48292de4x6f2c26e1ea9c1756@mail.gmail.com","subject":"Re: Cherry-pick with symlinks fails horribly","fromName":"Alexander Gladysh","fromEmail":"agladysh@gmail.com","sentAt":"2010-03-10T18:54:05Z","receivedAt":"2010-03-10T18:54:05Z","isPatch":false,"sender":{"key":"agladysh@gmail.com","avatar":"https://avatars.githubusercontent.com/u/38239?v=4"},"body":"Sorry to nag, but... any help?\n\nAlexander.\n\nOn Tue, Mar 9, 2010 at 04:28, Alexander Gladysh wrote:\n> Hi, list!\n>\n> OS X 10.6.2\n> Git 1.7.0.2\n>\n> I'm complaining about Git symlink handling again. This time it is cherry-pick.\n>\n> In my repo I have a symlink pointing to a directory.\n>\n> I swap symlink with the directory in a single commit.\n>\n> Now, if I try to cherry-pick any later commit from the branch that has\n> that swap commit to a branch that have not, cherry-pick fails\n> horribly.\n>\n> See script to reproduce the bug below (run it in a clean directory).\n>\n> Output example:\n>\n> $ git cherry-pick \n>\n> Automatic cherry-pick failed.  After resolving the conflicts,\n> mark the corrected paths with 'git add ' or 'git rm '\n> and commit the result with:\n>\n>        git commit -c 6a398597ce7a00fe05f43ff88808303eb151dfb5\n>\n> $ git status # Note the \"Untracked files\" section\n>\n> # On branch master\n> # Changes to be committed:\n> #   (use \"git reset HEAD ...\" to unstage)\n> #\n> #       renamed:    a/f -> f1\n> #\n> # Unmerged paths:\n> #   (use \"git reset HEAD ...\" to unstage)\n> #   (use \"git add/rm ...\" as appropriate to mark resolution)\n> #\n> #       added by us:        b/a\n> #\n> # Untracked files:\n> #   (use \"git add ...\" to include in what will be committed)\n> #\n> #       b/a~HEAD\n>\n> (Also I've seen git reset --hard to fail afterwards, complaining it\n> can't delete a directory, but I can't reproduce it now.)\n>\n> I see a similar behaviour if I try to do interactive rebase accross\n> symlink swap commit.\n>\n> Alexander.\n>\n> #! /bin/bash\n>\n> git init\n>\n> mkdir a\n> touch a/f\n> git add a\n> git commit -m \"a\"\n>\n> mkdir b\n> ln -s ../a b/a\n> git add b\n> git commit -m \"b\"\n>\n> git checkout -b branch\n> rm b/a\n> mv a b/\n> ln -s b/a a\n> git add .\n> git commit -m \"swap\"\n>\n> touch f1\n> git add f1\n> git commit -m \"f1\"\n>\n> git checkout master\n>\n> git cherry-pick `git rev-parse branch` # This one breaks horribly\n>\n"},{"id":"136555","messageId":"201003110557.11268.chriscool@tuxfamily.org","threadId":"22961","inReplyTo":"c6c947f61003081728u48292de4x6f2c26e1ea9c1756@mail.gmail.com","subject":"Re: Cherry-pick with symlinks fails horribly","fromName":"Christian Couder","fromEmail":"chriscool@tuxfamily.org","sentAt":"2010-03-11T04:57:11Z","receivedAt":"2010-03-11T04:57:11Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Tuesday 09 March 2010 02:28:30 Alexander Gladysh wrote:\n> Hi, list!\n> \n> OS X 10.6.2\n> Git 1.7.0.2\n> \n> I'm complaining about Git symlink handling again. This time it is\n> cherry-pick.\n> \n> In my repo I have a symlink pointing to a directory.\n> \n> I swap symlink with the directory in a single commit.\n> \n> Now, if I try to cherry-pick any later commit from the branch that has\n> that swap commit to a branch that have not, cherry-pick fails\n> horribly.\n> \n> See script to reproduce the bug below (run it in a clean directory).\n> \n> Output example:\n> \n> $ git cherry-pick \n> \n> Automatic cherry-pick failed. After resolving the conflicts,\n> mark the corrected paths with 'git add ' or 'git rm '\n> and commit the result with:\n> \n> git commit -c 6a398597ce7a00fe05f43ff88808303eb151dfb5\n> \n> $ git status # Note the \"Untracked files\" section\n> \n> # On branch master\n> # Changes to be committed:\n> # (use \"git reset HEAD ...\" to unstage)\n> #\n> #\trenamed: a/f -> f1\n> #\n> # Unmerged paths:\n> # (use \"git reset HEAD ...\" to unstage)\n> # (use \"git add/rm ...\" as appropriate to mark resolution)\n> #\n> #\tadded by us: b/a\n> #\n> # Untracked files:\n> # (use \"git add ...\" to include in what will be committed)\n> #\n> #\tb/a~HEAD\n> \n> (Also I've seen git reset --hard to fail afterwards, complaining it\n> can't delete a directory, but I can't reproduce it now.)\n> \n> I see a similar behaviour if I try to do interactive rebase accross\n> symlink swap commit.\n> \n> Alexander.\n> \n> #! /bin/bash\n> \n> git init\n> \n> mkdir a\n> touch a/f\n> git add a\n> git commit -m \"a\"\n> \n> mkdir b\n> ln -s ../a b/a\n> git add b\n> git commit -m \"b\"\n> \n> git checkout -b branch\n> rm b/a\n> mv a b/\n> ln -s b/a a\n> git add .\n> git commit -m \"swap\"\n> \n> touch f1\n> git add f1\n> git commit -m \"f1\"\n> \n> git checkout master\n> \n> git cherry-pick `git rev-parse branch` # This one breaks horribly\n\nI can reproduce the bug here on Linux. And Git v1.6.0 has the same bug.\nSo I suspect an old bug in unpack_trees.c. I will try to have another look at \nit this evening, but I am not familiar with that code.\n\nThanks for the report,\nChristian.\n"},{"id":"136579","messageId":"c6c947f61003110416l40a85b6fg7ede2403a8f6961b@mail.gmail.com","threadId":"22961","inReplyTo":"201003110557.11268.chriscool@tuxfamily.org","subject":"Re: Cherry-pick with symlinks fails horribly","fromName":"Alexander Gladysh","fromEmail":"agladysh@gmail.com","sentAt":"2010-03-11T12:16:09Z","receivedAt":"2010-03-11T12:16:09Z","isPatch":false,"sender":{"key":"agladysh@gmail.com","avatar":"https://avatars.githubusercontent.com/u/38239?v=4"},"body":"On Thu, Mar 11, 2010 at 07:57, Christian Couder wrote:\n> On Tuesday 09 March 2010 02:28:30 Alexander Gladysh wrote:\n>> I'm complaining about Git symlink handling again. This time it is\n>>  cherry-pick.\n\n> I can reproduce the bug here on Linux. And Git v1.6.0 has the same bug.\n> So I suspect an old bug in unpack_trees.c. I will try to have another look at\n> it this evening, but I am not familiar with that code.\n\nI have found my old bug-report. There is even some patch in that thread.\n\nhttp://thread.gmane.org/gmane.comp.version-control.git/120741/\n\nNot sure if it is the same issue or if the patch was even merged in though...\n\nHTH,\nAlexander.\n"},{"id":"136634","messageId":"201003120448.22821.chriscool@tuxfamily.org","threadId":"22961","inReplyTo":"c6c947f61003110416l40a85b6fg7ede2403a8f6961b@mail.gmail.com","subject":"Re: Cherry-pick with symlinks fails horribly","fromName":"Christian Couder","fromEmail":"chriscool@tuxfamily.org","sentAt":"2010-03-12T03:48:22Z","receivedAt":"2010-03-12T03:48:22Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Thursday 11 March 2010 13:16:09 Alexander Gladysh wrote:\n> On Thu, Mar 11, 2010 at 07:57, Christian Couder \nwrote:\n> > On Tuesday 09 March 2010 02:28:30 Alexander Gladysh wrote:\n> >> I'm complaining about Git symlink handling again. This time it is\n> >> cherry-pick.\n> >\n> > I can reproduce the bug here on Linux. And Git v1.6.0 has the same bug.\n> > So I suspect an old bug in unpack_trees.c. I will try to have another\n> > look at it this evening, but I am not familiar with that code.\n> \n> I have found my old bug-report. There is even some patch in that thread.\n> \n> http://thread.gmane.org/gmane.comp.version-control.git/120741/\n> \n> Not sure if it is the same issue or if the patch was even merged in\n> though...\n\nThe patch was merged:\n\ncommit 77716755cbdf970fa0814a5f77c884b1f17693de\nAuthor: Kjetil Barvik \nDate: Sun Jun 14 15:08:28 2009 +0200\n\n lstat_cache: guard against full match of length of 'name' parameter\n\nso I think it is a different issue, but feel free to test.\n\nAnyway when looking at t/t6035-merge-dir-to-symlink.sh, we can see that there \nare still 2 broken tests:\n\n$ ./t6035-merge-dir-to-symlink.sh\n* ok 1: create a commit where dir a/b changed to symlink\n* ok 2: keep a/b-2/c/d across checkout\n* ok 3: checkout should not have deleted a/b-2/c/d\n* ok 4: setup for merge test\n* ok 5: do not lose a/b-2/c/d in merge (resolve)\n* still broken 6: do not lose a/b-2/c/d in merge (recursive)\n* ok 7: setup a merge where dir a/b-2 changed to symlink\n* ok 8: merge should not have conflicts (resolve)\n* still broken 9: merge should not have conflicts (recursive)\n* still have 2 known breakage(s)\n* passed all remaining 7 test(s)\n\nSo it looks like breakages in this area are known, though perhaps not your \nparticular breakage.\n\nBest regards,\nChristian.\n"},{"id":"136639","messageId":"7vljdyt7h8.fsf@alter.siamese.dyndns.org","threadId":"22961","inReplyTo":"201003120448.22821.chriscool@tuxfamily.org","subject":"Re: Cherry-pick with symlinks fails horribly","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-03-12T05:49:23Z","receivedAt":"2010-03-12T05:49:23Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Christian Couder writes:\n\n> Anyway when looking at t/t6035-merge-dir-to-symlink.sh, we can see that\n> there are still 2 broken tests:\n>\n> $ ./t6035-merge-dir-to-symlink.sh\n> ...\n> * ok 5: do not lose a/b-2/c/d in merge (resolve)\n> * still broken 6: do not lose a/b-2/c/d in merge (recursive)\n> * ok 7: setup a merge where dir a/b-2 changed to symlink\n> * ok 8: merge should not have conflicts (resolve)\n> * still broken 9: merge should not have conflicts (recursive)\n> * still have 2 known breakage(s)\n> * passed all remaining 7 test(s)\n>\n> So it looks like breakages in this area are known, though perhaps not your \n> particular breakage.\n\nThe above shows that resolve passes the same tests that recursive fails,\nwhich means that the breakage is likely to be in recursive, and not in\nunpack-trees, as you seemt to have guessed earlier. If cherry-pick were\nstill a shell script, we could easily test that conjecture by letting you\ntry running it using resolve instead of recursive, but things like that\nhas got a lot harder to do these days since many things were rewritten in\nC (sigh).\n\nIt might not be a bad idea to teach a hidden primarily-for-debugging\noption to \"cherry-pick\" to let it use resolve instead of recursive for\ncases like this.\n"},{"id":"137770","messageId":"201003250601.44871.chriscool@tuxfamily.org","threadId":"22961","inReplyTo":"7vljdyt7h8.fsf@alter.siamese.dyndns.org","subject":"Re: Cherry-pick with symlinks fails horribly","fromName":"Christian Couder","fromEmail":"chriscool@tuxfamily.org","sentAt":"2010-03-25T05:01:44Z","receivedAt":"2010-03-25T05:01:44Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Friday 12 March 2010 06:49:23 Junio C Hamano wrote:\n> Christian Couder writes:\n> > Anyway when looking at t/t6035-merge-dir-to-symlink.sh, we can see that\n> > there are still 2 broken tests:\n> >\n> > $ ./t6035-merge-dir-to-symlink.sh\n> > ...\n> > * ok 5: do not lose a/b-2/c/d in merge (resolve)\n> > * still broken 6: do not lose a/b-2/c/d in merge (recursive)\n> > * ok 7: setup a merge where dir a/b-2 changed to symlink\n> > * ok 8: merge should not have conflicts (resolve)\n> > * still broken 9: merge should not have conflicts (recursive)\n> > * still have 2 known breakage(s)\n> > * passed all remaining 7 test(s)\n> >\n> > So it looks like breakages in this area are known, though perhaps not\n> > your particular breakage.\n> \n> The above shows that resolve passes the same tests that recursive fails,\n> which means that the breakage is likely to be in recursive, and not in\n> unpack-trees, as you seemt to have guessed earlier. \n\nYes, you are right the breakage is in recursive as it works with resolve.\n\n> If cherry-pick were\n> still a shell script, we could easily test that conjecture by letting you\n> try running it using resolve instead of recursive, but things like that\n> has got a lot harder to do these days since many things were rewritten in\n> C (sigh).\n> \n> It might not be a bad idea to teach a hidden primarily-for-debugging\n> option to \"cherry-pick\" to let it use resolve instead of recursive for\n> cases like this.\n\nI will send an RFC patch series to do that. I used it to check that the test \ncase works with the resolve strategy.\n\nBest regards,\nChristian.\n"}]}