{"thread":{"id":"8022","subject":"git rebase chokes on directory -> symlink -> directory","startedAt":"2007-05-08T01:08:12Z","lastAt":"2007-05-14T04:37:44Z","messageCount":17,"participants":["H. Peter Anvin","Alex Riesen","Junio C Hamano","Johannes Sixt","Shawn O. Pearce","Linus Torvalds"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"41376","messageId":"463FCD7C.4020009@zytor.com","threadId":"8022","inReplyTo":null,"subject":"git rebase chokes on directory -> symlink -> directory","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2007-05-08T01:08:12Z","receivedAt":"2007-05-08T01:08:12Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"The following tree:\n\nhttp://git.kernel.org/?p=linux/kernel/git/hpa/linux-2.6-newsetup.git;a=summary\n\n... has one commit which changes arch/x86_64/boot from a directory to a\nsymlink, and another one which changes it back.  Apparently as a result,\ngit rebase dies horribly; on the first change it requires manual fixup,\nbut it crashes on the second, with or without -m.\n\nThe specific task attempted is to rebase the main branch of that tree\nonto the current Linus tree, a989705c4cf6e6c1a339c95f9daf658b4ba88ca8.\n\n\t-hpa\n"},{"id":"41505","messageId":"20070508215009.GA2670@steel.home","threadId":"8022","inReplyTo":"463FCD7C.4020009@zytor.com","subject":"Re: git rebase chokes on directory -> symlink -> directory","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-05-08T21:50:10Z","receivedAt":"2007-05-08T21:50:10Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"H. Peter Anvin, Tue, May 08, 2007 03:08:12 +0200:\n> The following tree:\n> \n> http://git.kernel.org/?p=linux/kernel/git/hpa/linux-2.6-newsetup.git;a=summary\n> \n> ... has one commit which changes arch/x86_64/boot from a directory to a\n> symlink, and another one which changes it back.  Apparently as a result,\n> git rebase dies horribly; on the first change it requires manual fixup,\n> but it crashes on the second, with or without -m.\n\nWhat kind of manual fixup did you do? I tried to reproduce it, and did\nthe following:\n\n    git clone --reference ~/linux.git git://git.kernel.org/pub/scm/linux/kernel/git/hpa/linux-2.6-newsetup.git\n    cd linux-2.6-newsetup.git\n    git rebase a989705c4cf6e6c1a339c95f9daf658b4ba88ca8\n\nIt stopped at 'Revert \"x86-64: Make arch/x86-64/boot a symlink to\narch/i386/boot\"' aka cd312503f8e8a88895b12bf810677406284142e6.\nI went on:\n\n    rm arch/x86-64/boot\n    git checkout cd312503f8e8a88895b12bf810677406284142e6 arch/x86-64/boot\n    git rebase --continue\n\nAnd then it just continued until all commits were rebased.\nI have a very recent git, so maybe that's why it worked.\n"},{"id":"41527","messageId":"46413565.3090503@zytor.com","threadId":"8022","inReplyTo":"20070508215009.GA2670@steel.home","subject":"Re: git rebase chokes on directory -> symlink -> directory","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2007-05-09T02:43:49Z","receivedAt":"2007-05-09T02:43:49Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Alex Riesen wrote:\n\n> \n> What kind of manual fixup did you do? I tried to reproduce it, and did\n> the following:\n> \n>     git clone --reference ~/linux.git git://git.kernel.org/pub/scm/linux/kernel/git/hpa/linux-2.6-newsetup.git\n>     cd linux-2.6-newsetup.git\n>     git rebase a989705c4cf6e6c1a339c95f9daf658b4ba88ca8\n> \n> It stopped at 'Revert \"x86-64: Make arch/x86-64/boot a symlink to\n> arch/i386/boot\"' aka cd312503f8e8a88895b12bf810677406284142e6.\n> I went on:\n> \n>     rm arch/x86-64/boot\n>     git checkout cd312503f8e8a88895b12bf810677406284142e6 arch/x86-64/boot\n>     git rebase --continue\n> \n> And then it just continued until all commits were rebased.\n> I have a very recent git, so maybe that's why it worked.\n> \n\nMine stops already at the directory -> symlink checkin (the above is the\nsymlink -> directory one), but your trick of using \"git checkout\" as a\ntrick to resolve things helped for both... eventually :-/\n\nEither way, it's still a bug that it stops for either checkin, but it's\nnot blocking my work anymore.\n\n\t-hpa\n"},{"id":"41552","messageId":"81b0412b0705090050i644a18c2g12c74462ab88163a@mail.gmail.com","threadId":"8022","inReplyTo":"46413565.3090503@zytor.com","subject":"Re: git rebase chokes on directory -> symlink -> directory","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-05-09T07:50:34Z","receivedAt":"2007-05-09T07:50:34Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 5/9/07, H. Peter Anvin <hpa@zytor.com> wrote:\n>\n> Mine stops already at the directory -> symlink checkin (the above is the\n> symlink -> directory one), but your trick of using \"git checkout\" as a\n> trick to resolve things helped for both... eventually :-/\n>\n\nHmm. What Git version do you have?\n\n> Either way, it's still a bug that it stops for either checkin, ...\n\nRight. And because it is a bug, I'd like to have it fixed.\nSo, what did you do in that fixup?\n"},{"id":"41625","messageId":"4641FDAF.3090608@zytor.com","threadId":"8022","inReplyTo":"81b0412b0705090050i644a18c2g12c74462ab88163a@mail.gmail.com","subject":"Re: git rebase chokes on directory -> symlink -> directory","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2007-05-09T16:58:23Z","receivedAt":"2007-05-09T16:58:23Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Alex Riesen wrote:\n> On 5/9/07, H. Peter Anvin <hpa@zytor.com> wrote:\n>>\n>> Mine stops already at the directory -> symlink checkin (the above is the\n>> symlink -> directory one), but your trick of using \"git checkout\" as a\n>> trick to resolve things helped for both... eventually :-/\n>>\n> \n> Hmm. What Git version do you have?\n\nNot sure anymore, because I ran a systemwide upgrade late last night.\n*Now* I have git-1.5.1.4, but I think I had 1.5.1.2 before.\n\n>> Either way, it's still a bug that it stops for either checkin, ...\n> \n> Right. And because it is a bug, I'd like to have it fixed.\n> So, what did you do in that fixup?\n\nI'm sorry, I'm not sure I understand the question, in particular, I'm\ngetting the feeling I'm not sure what \"that fixup\" refers to.\n\n\t-hpa\n"},{"id":"41668","messageId":"20070509213902.GA2593@steel.home","threadId":"8022","inReplyTo":"4641FDAF.3090608@zytor.com","subject":"Re: git rebase chokes on directory -> symlink -> directory","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-05-09T21:39:02Z","receivedAt":"2007-05-09T21:39:02Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"H. Peter Anvin, Wed, May 09, 2007 18:58:23 +0200:\n> >>\n> >> Mine stops already at the directory -> symlink checkin (the above is the\n> >> symlink -> directory one), but your trick of using \"git checkout\" as a\n> >> trick to resolve things helped for both... eventually :-/\n> > \n> > Hmm. What Git version do you have?\n> \n> Not sure anymore, because I ran a systemwide upgrade late last night.\n> *Now* I have git-1.5.1.4, but I think I had 1.5.1.2 before.\n\n... and the rebase you tried originally works now? Or you didn't try?\nThere were changes (substantial changes) in this area, so it might be\nfixed. If not, I'd like to hear, I personally rely on rebase heavily.\n\n> >> Either way, it's still a bug that it stops for either checkin, ...\n> > \n> > Right. And because it is a bug, I'd like to have it fixed.\n> > So, what did you do in that fixup?\n> \n> I'm sorry, I'm not sure I understand the question, in particular, I'm\n> getting the feeling I'm not sure what \"that fixup\" refers to.\n> \n\n>From your original report:\n\n\"git rebase dies horribly; on the first change it requires manual fixup,\nbut it crashes on the second, with or without -m.\"\n\nYou mentioned that on the first change (I assumed it is the first time\ngit-rebase stopped, complained, and asked for your help) \"it\" requires\na \"manual fixup\". Which I assume you did, as it crashed on \"second\"\n(stop?). The \"manual fixup\" from the original report, what was it?\nCan you remember or find the sequence of commands you did before \"it\ncrashed on second\"?\n"},{"id":"41680","messageId":"46424ECC.6030907@zytor.com","threadId":"8022","inReplyTo":"20070509213902.GA2593@steel.home","subject":"Re: git rebase chokes on directory -> symlink -> directory","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2007-05-09T22:44:28Z","receivedAt":"2007-05-09T22:44:28Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Alex Riesen wrote:\n>>>> Either way, it's still a bug that it stops for either checkin, ...\n>>> Right. And because it is a bug, I'd like to have it fixed.\n>>> So, what did you do in that fixup?\n>> I'm sorry, I'm not sure I understand the question, in particular, I'm\n>> getting the feeling I'm not sure what \"that fixup\" refers to.\n>>\n> \n> From your original report:\n> \n> \"git rebase dies horribly; on the first change it requires manual fixup,\n> but it crashes on the second, with or without -m.\"\n> \n> You mentioned that on the first change (I assumed it is the first time\n> git-rebase stopped, complained, and asked for your help) \"it\" requires\n> a \"manual fixup\". Which I assume you did, as it crashed on \"second\"\n> (stop?). The \"manual fixup\" from the original report, what was it?\n> Can you remember or find the sequence of commands you did before \"it\n> crashed on second\"?\n\nAh, I used your technique of removing everything manually when the\nrebase failed, and then doing a \"git checkout\" of arch/x86_64/boot.\nThat seemed to work.  I actually logged the commands, but threw out the\nlog after it worked, figuring it didn't tell you anything new :(\n\nTrying to do a rebase again with 1.5.1.4 and see how it works gives only\none stop instead of two, so it's \"halfway there\":\n\n: tazenda 14 ; git rebase stock\nFirst, rewinding head to replay your work on top of it...\nHEAD is now at a989705... Merge\ngit://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6\n\nApplying 'x86 setup code rewrite: initial development snapshot'\n\nWrote tree bf3a4e990978bad7669dac117b0d482e53f1bcd7\nCommitted: f98b2dc7eff7f2ce9d039af794e7f0062cc42bf9\n\nApplying 'MAINTAINERS: formally take responsibility for the i386 boot code'\n\nWrote tree 237806033e5c789752aa555a5aaba17c8b650c4c\nCommitted: e4fb08878f0fe2c2e72665315c35e698ece08101\n\nApplying 'x86 setup: printf.c needs code16gcc.h'\n\nWrote tree 8be170c7240961ff47d13045412b2f8d66d54e20\nCommitted: 2a103e2db001d0d6a852861ea209b34ba97ffc6a\n\nApplying 'x86 setup: in tty.c, actually tell it what character to print'\n\nWrote tree 0e487f781b874a8025e7fcd74e055abeee5ebe2e\nCommitted: da62daaf237756aab1330f8dc4842ca5e5fa4ac9\n\nApplying 'build: setup sectors doesn't include the boot sector'\n\nWrote tree 66192f639721713010b65ddb6c40f0d7a1f51a0b\nCommitted: 5794cf95386551f0f97b7cae877845cbbb3ebfea\n\nApplying 'x86 setup: segment descriptors need to be Present'\n\nWrote tree a3aa7db9741d1dc57007d97152a337b6532fc588\nCommitted: de616f57959c3b62a1ac544858a8bd41696d59dd\n\nApplying 'x86 setup: make the video setup code actually do something...'\n\nWrote tree 9358db854ca73d9f6ac344c9dbc397a9913b4c86\nCommitted: 13a363f40ff51d61d5c553e529555c32425d7553\n\nApplying 'x86 setup: fix missing semicolon in video-ati.c'\n\nWrote tree 0bbd82ef2e2bc2128c29ee8f8ca04399b86f8a98\nCommitted: d948a8ebb7f26f030264153fd801aca5dca47603\n\nApplying 'x86 setup: fix memcmp_[fg]s()'\n\nWrote tree 368f27ee12eeeebfaad11bfabf6e087638e94b10\nCommitted: d5a63882787f4a927910307f2e8f3df0534643f6\n\nApplying 'x86 setup: advance one e820 descriptor at a time...'\n\nWrote tree e7fb596232ed18cbddb6507ce8cb67e09a6326c9\nCommitted: ccfd63579f5df793701d44c46dd575629eabad85\n\nApplying 'x86 setup: Call INT 15h AX=E820h properly'\n\nWrote tree bb010d0e1224ccbf4a0e201dab191448e84405d5\nCommitted: a84a8eab7e7d3708ad9cfdee67981eafe3a21b38\n\nApplying 'x86 setup: remove assembly implementation of putchar and puts'\n\nWrote tree dc8d970b62d1be70175e04bed26dfa644f521cfd\nCommitted: 7356f51c11fc0e5f363a5f06df5274a7ccea73f5\n\nApplying 'x86 setup: Sadly, Cirrus removed extended text modes from\ntheir BIOS.'\n\nWrote tree 48560789f0ed319f77b529ea3f31e11126df6221\nCommitted: 06a5abda109eeadb34f3087b51e8a1f4cc69c3f3\n\nApplying 'x86 setup: if no specific video mode ID is given, generate one'\n\nWrote tree 0366a71399c33ca08590aaa67df6438122529867\nCommitted: 56eb2476b71a917747bf6ea111568f9e5ba85e2c\n\nApplying 'x86 setup: drop video mode range checking'\n\nWrote tree bd90ee84715e4eff9f1fafe7efc3c6440e6be69e\nCommitted: 668bf617eb273ddcefb007e3c5ec9bb4aa022894\n\nApplying 'x86 setup: video.c: clean up unused stuff'\n\nWrote tree 1a2d47f784b5b64e7893a3364cbef1c8ba2a39cd\nCommitted: f38134d1296f5a09887b79cc6c4b13e34f77f293\n\nApplying 'x86 setup: a20.c: make empty_8042() return status'\n\nAdds trailing whitespace.\n.dotest/patch:26:\nwarning: 1 line adds trailing whitespaces.\nWrote tree 0f46a1846afcaf61d7c4416d7f308ffd9d87d69c\nCommitted: 18a9e385504b85daa0e293e2a60309e34de4548e\n\nApplying 'x86 setup: Modern ATI cards pass the probe but lacks the modes.'\n\nWrote tree 775608a82bd3783f5ba5dc00f7b4b7c39eb463ed\nCommitted: 0ed82f2809ec04d4db243d833e8cb5fcc029cd3e\n\nApplying 'x86 setup: video.c: correct the handling of special mode numbers'\n\nWrote tree 9dae6d4dcc4bc2b98114a5a3ae6ff88bea7c60c3\nCommitted: af2b591e9c529b35b4cbb006b417cd6f16b87504\n\nApplying 'x86 setup: remove references to obsolete probes'\n\nWrote tree f5605b2ab57ef0e52129c1809fa03c4b804b05cd\nCommitted: 30448725fe01982ab4ce7d28af609783c9d7eb32\n\nApplying 'x86 setup: implement APM BIOS probe'\n\nWrote tree e46f5c4e318fa5f30ea221b90bdaa301876945cf\nCommitted: 293ae9fb21ebbfa6c834a016a20037a19b97bc5e\n\nApplying 'x86 setup: clobber registers in keyboard BIOS call'\n\nWrote tree 98610c0970730f62d05412eaaadcec1528d94a98\nCommitted: 4b89273f6c78fe28b6f4aea161f64aa7ac2b8724\n\nApplying 'x86 setup: tag functions noreturn; error message on A20 failure'\n\nAdds trailing whitespace.\n.dotest/patch:78:\nwarning: 1 line adds trailing whitespaces.\nWrote tree 605c96e3555b7bbbfd7b06306b225becff4ab09e\nCommitted: 72bd91360bbe365dc152e39f03229152c1e4f978\n\nApplying 'x86 setup: whitespace cleanup'\n\nWrote tree 27230a23ba2f8b0aac3dddc264d7f4a28d18f8dc\nCommitted: 35f72771c466d83cc551bf81dfed22326048080e\n\nApplying 'x86 setup: add CPU feature detect/abort on insufficient featurage'\n\nAdds trailing whitespace.\n.dotest/patch:20:setup-y                += header.o main.o mca.o\nmemory.o pm.o pmjump.o\nwarning: 1 line adds trailing whitespaces.\nWrote tree 405fde3817d89e7aba618bda965d4bcc24e825d5\nCommitted: 18e25bde0d246d828931ebd6450c63a4091e0fc1\n\nApplying 'x86 setup: whitespace cleanup'\n\nWrote tree 8124b48b7b985ae31062356df521462e4420f09a\nCommitted: 91d417b3def3b38aeba165282746fa82e6de0fad\n\nApplying 'x86 setup: files missing from previous checkin (cpu.c, cpureq.c)'\n\nWrote tree 2be68b923f0b413701f5f57b93aaca42cc126e49\nCommitted: a312ada92fdff09e0ca6cf60724353f8f5d3578a\n\nApplying 'x86 setup: remove unused verify_cpu.S'\n\nWrote tree 7f3ebf06770406f4936ace5aef8a1b20e2676563\nCommitted: 0eaf9d747d1e0677aef4c762333b8b1988fe5ce3\n\nApplying 'x86 setup: compile with -DSETUP'\n\nWrote tree 475e43922e02adad5ff1e9e1c77df1ff26cbdcc6\nCommitted: b843ca098801e962fed08f20ee99fb2f5cbd18fd\n\nApplying 'x86 setup: cpu detection cleanups'\n\nWrote tree d72cabf9f1812da55506c38ddd88ef5dcd42f535\nCommitted: 45adb1922193dc5204d5bf07de9e5a8939b2688c\n\nApplying 'x86 setup: remove bogus \"static\"'\n\nWrote tree 17281ee44c7ce686366464985b8d1a436d6d7468\nCommitted: 79ed2a26f0de632d0fb9cf36ccd30d99267975a2\n\nApplying 'x86 setup: use CONFIG_X86_MINIMUM_CPU_MODEL'\n\nWrote tree 1e3a29b3de3dd86c46d2900485ef8206f948a72d\nCommitted: ed41358ab168c7e7e9eb1ddff44d995eb339879e\n\nApplying 'x86: Kconfig.cpu: the minimum CPU model is always 3;\nWP_WORKS_OK = i486'\n\nWrote tree d174addf546223baf87598db7673872608f6cb2c\nCommitted: 84c13f3993b812efbc781ae106fecc0e7478809e\n\nApplying 'x86: make the handling of required features consistent'\n\nWrote tree c96d44bd1b12f0b4090db2bc60ffec5c54c1c4da\nCommitted: 48091cdd868350c0c98b0b11592606e850058737\n\nApplying 'x86 setup: use the required masks from <asm/required-features.h>'\n\nAdds trailing whitespace.\n.dotest/patch:145:\nAdds trailing whitespace.\n.dotest/patch:156:\nAdds trailing whitespace.\n.dotest/patch:190:\nAdds trailing whitespace.\n.dotest/patch:200:\nAdds trailing whitespace.\n.dotest/patch:248:\nwarning: squelched 1 whitespace error\nwarning: 6 lines add trailing whitespaces.\nWrote tree 7f53ccc902a878e6bdae0446147b79f693bbbfe3\nCommitted: 22f4301757277e2d542fab95529c664413225efe\n\nApplying 'x86 setup: remove reference to obsolete cpureq.c'\n\nWrote tree c77da037a2247c8f577e5167d6bfed833484c3a5\nCommitted: ed056f881d6c0698c233ee888d9c4e798c8ba736\n\nApplying 'x86 setup: apparently $(src) is insufficient, needs\n$(srctree)/$(src)'\n\nWrote tree 53ed308ffc67dd7bbca326facb578bc56091855c\nCommitted: 530888f2f6f9dceb7a3d1d5e2e5a5c4d56606136\n\nApplying 'x86 setup: bootlin is *so* dead...'\n\nWrote tree 65574110a6702b6d2616441ce74e5c02bd53cb6c\nCommitted: f20bb507355d38b871f4bb2034b9303f4b0742e0\n\nApplying 'x86 setup: paranoia: clear the high half of %esp'\n\nAdds trailing whitespace.\n.dotest/patch:15:\nwarning: 1 line adds trailing whitespaces.\nWrote tree 52d253ca3ff8dd7f8394762720501c99614a1b83\nCommitted: f9040dd40db9f08650201f2f32f56186b31a7dcb\n\nApplying 'x86 setup: add missing linker script'\n\nWrote tree f9dd325985592248b878c4df0646fbc430e9cdd6\nCommitted: 877594775c44a72c802f4e8cba9db5db63223aa4\n\nApplying 'x86 setup: cleanups for compatibility with x86-64'\n\nAdds trailing whitespace.\n.dotest/patch:125:\nwarning: 1 line adds trailing whitespaces.\nWrote tree d83528199922e40076dc373cd9d24daba9a15516\nCommitted: 907963662ce663a8deb3594c6c7f9783de1cbe3b\n\nApplying 'x86-64: add CONFIG_PHYSICAL_ALIGN to match i386'\n\nWrote tree f6d6abdee2fceed761eef217dcc1c7ed0de9877e\nCommitted: a015ea48164d9e6a8ab317c26cbe555c3032f699\n\nApplying 'x86-64: <asm/segment.h>: add boot segment descriptors'\n\nWrote tree e3abd746b0f94b58ed510264a62b123e995f08b6\nCommitted: 8e00cfafbf108a2801fb0ec8b824962b1e073d55\n\nApplying 'x86-64: fix compilation errors due to required-features.h change'\n\nWrote tree a1626723ccdd339ac8ef0764c77b2cdccdfb2f26\nCommitted: 355b0dc242a05f72c7bc1ad8f73fdc6e82a39afc\n\nApplying 'x86-64: verify_cpu.S: use new masks'\n\nWrote tree 117fbd16776cc9b201a0f76c9f3910cc7c1f8fa6\nCommitted: 14b6bc6f64844958c7f923ee46ce4e2356e21c08\n\nApplying 'x86: unify <asm/boot.h>'\n\nWrote tree ce269d002a4645b5ef54b1f8eef086a43498c81e\nCommitted: d84e3cc9eb73c7feb084b35303e45828917e3115\n\nApplying 'x86: Complete <asm/cpufeature.h> with the union of i386 and\nx86-64'\n\nWrote tree 3f40077f38ceb45312a780390f8d8d5eb98ffe17\nCommitted: 03d199b61342108a9f37978bec06626710284cd1\n\nApplying 'x86-64: rearrange includes due to unifications and inclusion\nfrom setup'\n\nSpace in indent is followed by a tab.\n.dotest/patch:44:               \"661:\\n\\tlock; \"\nwarning: 1 line adds trailing whitespaces.\nWrote tree 8f86e02ef672c98ae3519b9b3fabb3701a0ab1b9\nCommitted: 147328a824c71437259baf9a63fe03762bba74e0\n\nApplying 'x86-64: Make arch/x86-64/boot a symlink to arch/i386/boot'\n\nWrote tree 9bc7ffd5d07a49c5a83fc8f9a680473995aa6c57\nCommitted: a859f67570bf62d2a602d27aa34a674e6645ca24\n\nApplying 'x86: fix the definition of struct screen_info'\n\nWrote tree 258e5053597a572954943cb5b895e4462e6491fb\nCommitted: 951cf2086f5c2055e93b0db22c1064829bedc74e\n\nApplying 'x86: fix differences between i386 and x86-64 <asm/e820.h>'\n\nWrote tree 6e4f4ed1de0a6736fb298d4e1adcae3b60f7a151\nCommitted: 3bec0726b8cfa624492b35659c5a13d484a1bc89\n\nApplying 'i386: change %lu to %u in arch/i386/kernel/e820.h'\n\nWrote tree b05d8462dd9ce61fb32f61d2c9819877afe6be94\nCommitted: 7ab473d60f7bda2e7f7341bd9ca88610c5c440c5\n\nApplying 'x86: move the bootparam structure definition into include/'\n\nWrote tree 3865d940f5be27cf70fe54aff3825b1f6c676a01\nCommitted: 3b5b95528bcf5487f79e659fe6346377955dd654\n\nApplying 'x86 setup: E820MAX is a definitional constant; no need to use\nsizeof hacks'\n\nWrote tree 6ba2914fb480e88633a7da7700dce60b1e619c22\nCommitted: 3db11fa860f9b06bf1b50f3fe698f0c6fb9e55ca\n\nApplying 'x86 setup: boot_params.e820_map is just the map, not the\ncount; adjust'\n\nWrote tree 75308a18a561335d5a6a3613b51e130f43fcb00c\nCommitted: 4d6dea0f6c8ec5ac8580bcaee1c8d52f5d35e55a\n\nApplying 'x86 setup: use 0x1e4 as scratch, instead of 0x3c'\n\nWrote tree 55fe315b3a931bdb3f1ea96ebc5098bcc24b0610\nCommitted: eca97ac06fa0f8d17b1ec974c890642afea62555\n\nApplying 'x86-64: It appears MTRR isn't a required feature after all.'\n\nWrote tree 56fc138a5b01818142e200fa35921570270b53ac\nCommitted: 72c0fc6ecc2661245ae1fc42210a808a0ef63da1\n\nApplying 'Revert \"x86-64: Make arch/x86-64/boot a symlink to\narch/i386/boot\"'\n\nAdds trailing whitespace.\n.dotest/patch:117:FDARGS =\nAdds trailing whitespace.\n.dotest/patch:350: * Page 0 is deliberately kept safe, since System\nManagement Mode code in\nAdds trailing whitespace.\n.dotest/patch:352: * useful for future device drivers that either access\nthe BIOS via VM86\nAdds trailing whitespace.\n.dotest/patch:648: *\nAdds trailing whitespace.\n.dotest/patch:649: * This is a collection of several routines from\ngzip-1.0.3\nerror: arch/x86_64/boot/.gitignore: already exists in working directory\nerror: arch/x86_64/boot/Makefile: already exists in working directory\nerror: arch/x86_64/boot/compressed/Makefile: already exists in working\ndirectory\nerror: arch/x86_64/boot/compressed/head.S: already exists in working\ndirectory\nerror: arch/x86_64/boot/compressed/misc.c: already exists in working\ndirectory\nerror: arch/x86_64/boot/compressed/vmlinux.lds: already exists in\nworking directory\nerror: arch/x86_64/boot/compressed/vmlinux.scr: already exists in\nworking directory\nerror: arch/x86_64/boot/install.sh: already exists in working directory\nerror: arch/x86_64/boot/mtools.conf.in: already exists in working directory\nerror: arch/x86_64/boot/tools/.gitignore: already exists in working\ndirectory\nerror: arch/x86_64/boot/tools/build.c: already exists in working directory\nUsing index info to reconstruct a base tree...\nAdds trailing whitespace.\n<stdin>:117:FDARGS =\nAdds trailing whitespace.\n<stdin>:350: * Page 0 is deliberately kept safe, since System Management\nMode code in\nAdds trailing whitespace.\n<stdin>:352: * useful for future device drivers that either access the\nBIOS via VM86\nAdds trailing whitespace.\n<stdin>:648: *\nAdds trailing whitespace.\n<stdin>:649: * This is a collection of several routines from gzip-1.0.3\nwarning: squelched 26 whitespace errors\nwarning: 31 lines add trailing whitespaces.\nFalling back to patching base and 3-way merge...\nfatal: Untracked working tree file\n'arch/x86_64/boot/compressed/Makefile' would be overwritten by merge.\nFailed to merge in the changes.\nPatch failed at 0058.\n\nWhen you have resolved this problem run \"git rebase --continue\".\nIf you would prefer to skip this patch, instead run \"git rebase --skip\".\nTo restore the original branch and stop rebasing run \"git rebase --abort\".\n: tazenda 15 ; ls -ld arch/x86_64/boot\nlrwxrwxrwx 1 hpa hpa 12 May  9 15:41 arch/x86_64/boot -> ../i386/boot/\n: tazenda 16 ; rm -f arch/x86_64/boot\n: tazenda 17 ; head -1 .dotest/0058\nFrom cd312503f8e8a88895b12bf810677406284142e6 Mon Sep 17 00:00:00 2001\n: tazenda 18 ; git checkout cd312503f8e8a88895b12bf810677406284142e6\narch/x86_64/boot\n: tazenda 19 ; ls -ld arch/x86_64/boot\ndrwxrwxr-x 4 hpa hpa 4096 May  9 15:42 arch/x86_64/boot/\n: tazenda 20 ; git rebase --continue\n\nApplying 'Revert \"x86-64: Make arch/x86-64/boot a symlink to\narch/i386/boot\"'\n\nWrote tree 454be72b74038289064303704fa095e220539518\nCommitted: 7f942303bf26e31d10bf96b8d3fb3f1ee50a73a9\n\nApplying 'x86-64: use 0x1b4 as the scratch area in boot_params, not 0x3c'\n\nWrote tree a9634c1b3aa7bdc5d7de6d8fcdafaef851181f2b\nCommitted: 3f23a6bd448bc9b00718b412170ee2ed752eec8f\n\nApplying 'x86 setup: share code between i386 and x86-64'\n\nWrote tree 8397248a3723de8f0b31c6b5ed7f60d968c1631b\nCommitted: 72fe7620458f84e676dd40fdbe66835135e8a77c\n\nApplying 'x86-64: remove -traditional from AFLAGS'\n\nWrote tree 5a27b91ebc542b2769347837734890e2043d1b4a\nCommitted: 2f8b9521f04effda7b8150c4302aff469245c5ef\n\nApplying 'x86 setup: move all VESA-related code into video-vesa.c; add EDID'\n\nAdds trailing whitespace.\n.dotest/patch:86:\nwarning: 1 line adds trailing whitespaces.\nWrote tree e3289a29203434e4d683254f2aee077ddd4ae63c\nCommitted: f579842ed1a0dbabadc5359a7490c6a990bc7cb6\n\nApplying 'x86 setup: allow setting of VESA graphics modes; cleanups'\n\nAdds trailing whitespace.\n.dotest/patch:68:\nwarning: 1 line adds trailing whitespaces.\nWrote tree 44eebedb0cb6cb40a10aec011103d0271a5e3fd3\nCommitted: e9cbeb161b71ac237d9bf8c8afd15f9a35eedb20\n\nApplying 'x86 setup: whitespace cleanup'\n\nWrote tree eec8d62c5c9db76d918815f113d802a7a3d0d7f5\nCommitted: e3c55080c3db6dd3a9836fe7cd99bbdbb98bf84d\n\nApplying 'x86 setup: implement screen contents save/restore'\n\nWrote tree f135c21ddd2b6af70f97c1380dbcd460267ec177\nCommitted: 53be00bc3919c2c565776bb408ecdc0ea5dbc261\n\nApplying 'x86 setup: coppyright rPath, Inc.'\n\nWrote tree 47f7505f0436b527839190ee26029d520f17d25e\nCommitted: 2bf2c30e18fef98061ec0272e957d8faa387b6a0\n\nApplying 'i386 boot protocol: boot loaders should allow more heap for\nbzImage'\n\nWrote tree 4c5790a4a6ccf697e94729c3f5dec8d4d34a3dbc\nCommitted: 7439514e936c899639c6731f29a4988e7b66aa36\n\nApplying 'x86 setup: actually check the end of the heap.'\n\nWrote tree 3ed25ec4913189031ccfd5368969cfd77a1fbece\nCommitted: ab7cd52538086dc095289a981c9177e956abf354\n\nApplying 'x86 setup: when watching the setup size, take the stack into\naccount'\n\nWrote tree 34fa356d84aaa5241a281a8b01f04a059b5b353b\nCommitted: f3691d413e883e956213fc45cc132f7f76d7d3b7\n\nApplying 'x86 setup: Factor out the environment-independent part of the\nCPU check.'\n\nAdds trailing whitespace.\n.dotest/patch:239:\nAdds trailing whitespace.\n.dotest/patch:263:\nwarning: 2 lines add trailing whitespaces.\nWrote tree bae2277d4c4d40ba7b8fc11a25342ff4c023ef49\nCommitted: 85a238ecc2371cde07117d34524c71f9c96bc2f7\n\nApplying 'x86 setup: be more paranoid about the stack setup in header.S'\n\nWrote tree 1b5fa9f3d37d361e6b47bb4e7142ecbe89eb552c\nCommitted: 58643e76ef2630ae5e7b0541c5fd0e8183141a10\n\nApplying 'x86 setup: compile with -fomit-frame-pointer'\n\nWrote tree 3cd438bea06b27992940ce53fc56f16737d77c74\nCommitted: b36cd32f74a8be03dc23cd20b65c5c08dfae50ae\n\nApplying 'x86 setup: remove double nesting of a20_test()'\n\nWrote tree 941b5ec12d8a1e82949ad0cd3932537f91eb5e8d\nCommitted: 53cdb8049013d6f72d3cfb5be0bd9999fbff2a97\n\nApplying 'x86 setup: remove code moved from cpucheck.c -> cpu.c'\n\nWrote tree d83b020d216f92186026208576b5170b61ffd382\nCommitted: d5afa72f8eb28cc1e245b321dfa19fb620970900\n\nApplying 'x86 setup: swap cpu.c and cpucheck.c; rename functions'\n\nAdds trailing whitespace.\n.dotest/patch:489:\nAdds trailing whitespace.\n.dotest/patch:512:\nwarning: 2 lines add trailing whitespaces.\nWrote tree 41d79ce765e1174464c47bff61c4330e23bf6382\nCommitted: f2c63bb8e16d9b3c67ad1fdbc7ae1f5e18286662\n\nApplying 'x86 setup: add -fno-stack-protector; other Makefile fixes'\n\nWrote tree 65c5d385ff3bc54b65881629f72e4583c69a737e\nCommitted: 7ea7f8dbb4103d43b90fb6cc6f32c923b1f658e8\n\nApplying 'x86 setup: add missing file \"bitops.h\" missing from previous\ncheckins'\n\nWrote tree 01beebe04609804ef88762e794fdd71daff89bf1\nCommitted: 7eaa98edb81e9937128ce342f626177ee8a68941\n: tazenda 21 ;\n"},{"id":"41704","messageId":"7vmz0dmb2u.fsf@assigned-by-dhcp.cox.net","threadId":"8022","inReplyTo":"46424ECC.6030907@zytor.com","subject":"Re: git rebase chokes on directory -> symlink -> directory","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-10T06:44:57Z","receivedAt":"2007-05-10T06:44:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"H. Peter Anvin\" <hpa@zytor.com> writes:\n\n> Applying 'Revert \"x86-64: Make arch/x86-64/boot a symlink to\n> arch/i386/boot\"'\n>\n> Adds trailing whitespace.\n> .dotest/patch:117:FDARGS =\n> Adds trailing whitespace.\n> .dotest/patch:350: * Page 0 is deliberately kept safe, since System\n> Management Mode code in\n> Adds trailing whitespace.\n> .dotest/patch:352: * useful for future device drivers that either access\n> the BIOS via VM86\n> Adds trailing whitespace.\n> .dotest/patch:648: *\n> Adds trailing whitespace.\n> .dotest/patch:649: * This is a collection of several routines from\n> gzip-1.0.3\n> error: arch/x86_64/boot/.gitignore: already exists in working directory\n> error: arch/x86_64/boot/Makefile: already exists in working directory\n> error: arch/x86_64/boot/compressed/Makefile: already exists in working\n> directory\n> error: arch/x86_64/boot/compressed/head.S: already exists in working\n> directory\n> error: arch/x86_64/boot/compressed/misc.c: already exists in working\n> directory\n> error: arch/x86_64/boot/compressed/vmlinux.lds: already exists in\n> working directory\n> error: arch/x86_64/boot/compressed/vmlinux.scr: already exists in\n> working directory\n> error: arch/x86_64/boot/install.sh: already exists in working directory\n> error: arch/x86_64/boot/mtools.conf.in: already exists in working directory\n> error: arch/x86_64/boot/tools/.gitignore: already exists in working\n> directory\n> error: arch/x86_64/boot/tools/build.c: already exists in working directory\n\nAhh.\n\n * The tree state before this patch is applied has arch/x86_64/boot\n   as a symlink pointing at ../i386/boot/\n\n * The patch tries to remove arch/x86_64/boot symlink, and\n   create bunch of files there: .gitignore, Makefile, etc.\n\nThis is unfortunately a bit deeper than just git-rebase.  You\nexposed a nasty corner case problem in the stock git-apply,\nprobably one of the most important tool the kernel project uses\nevery day.\n\ngit-apply tries to be careful while applying patches; it never\ntouches the working tree until it is convinced that the patch\nwould apply cleanly.  One of the check it does is that when it\nknows a path is going to be created by the patch (in your\nexample, arch/x86_64/boot/.gitignore), it runs lstat() on the\npath to make sure it does not exist.\n\nThis leads to a false alarm.  Because we do not touch the\nworking tree before all the check passes, when we try to make\nsure that arch/x86_64/boot/.gitignore does not exist yet, we\nhaven't removed the arch/x86_64/boot symlink.  The lstat() check\nends up seeing arch/i386/boot/.gitignore through the\nyet-to-be-removed symlink, and says \"Hey, you already have a\nfile there, but what you fed me is a patch to create a new\nfile. I am not going to clobber what you have in the working\ntree.\"\n\nWe have similar checks to see a file we are going to modify does\nexist and match the preimage of the diff, which is done by\ndirectly opening and reading the file.\n\nFor a file we are going to delete, we make sure that it does\nexist and matches what is going to be removed (a removal patch\nrecords the full preimage, so we check what you have in your\nworking tree matches it in full -- otherwise we would risk\nlosing your local changes), which again is done by directly\nopening and reading the file.\n\nThese checks need to be adjusted so that they are not fooled by\nsymlinks in the middle.\n\n - To make sure something does not exist, first lstat().  If it\n   does not exist, it does not, so be happy.  If it _does_, we\n   might be getting fooled by a symlink in the middle, so break\n   leading paths and see if there are symlinks involved.  When\n   we are checking for a path a/b/c/d, if any of a, a/b, a/b/c\n   is a symlink, then a/b/c/d does _NOT_ exist, for the purpose\n   of our test.\n\n   This would fix this particular case you saw, and would not\n   add extra overhead in the usual case.\n\n - To make sure something already exists, first lstat().  If it\n   does not exist, barf (up to this, we already do).  Even if it\n   does seem to exist, we might be getting fooled by a symlink\n   in the middle, so make sure leading paths are not symlinks.\n\n   This would make the normal codepath much more expensive for\n   deep trees, which is a bit worrisome.\n\nWhen the code writes out the result after the checks pass, we\nfirst delete all the paths that are going to be deleted, and\nalso delete all the paths that are being modified.  Then in the\nsecond pass, we create all the paths that are being created and\nalso modified by writing their final contents out, while\ncreating leading directories as needed.  Because of this, a\npatch that removes a symlink and then makes it a directory to\nhold new files would first remove the symlink and then create\nthe directory at the right location and deposit newly created\nfiles there.  So I do not expect any change is needed in the\nwriteout codepath.\n\nBy the way, I noticed a few things while diagnosing this.\n\n * It was very considerate of you to leave \"rebase-1\" branch for\n   my postmortem in the repository.  You know what are needed\n   for debugging very well.\n\n * git-rebase with -m is dog slow.  There were people who\n   advocated to make it the default, but they probably are\n   either working in a very small project, or working on a\n   filesystem that even git-apply is slow that the speed\n   difference does not matter to them.\n"},{"id":"41716","messageId":"4642D009.9CEA2F3C@eudaptics.com","threadId":"8022","inReplyTo":"7vmz0dmb2u.fsf@assigned-by-dhcp.cox.net","subject":"Re: git rebase chokes on directory -> symlink -> directory","fromName":"Johannes Sixt","fromEmail":"j.sixt@eudaptics.com","sentAt":"2007-05-10T07:55:53Z","receivedAt":"2007-05-10T07:55:53Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Junio C Hamano wrote:\n>  * git-rebase with -m is dog slow.  There were people who\n>    advocated to make it the default, but they probably are\n>    either working in a very small project, or working on a\n>    filesystem that even git-apply is slow that the speed\n>    difference does not matter to them.\n\nHeh... you name it. But just yesterday rebase -m was a life saver for me\nbecause of its rename detection.\n\n-- Hannes\n"},{"id":"41781","messageId":"20070510220418.GK3141@spearce.org","threadId":"8022","inReplyTo":"7vmz0dmb2u.fsf@assigned-by-dhcp.cox.net","subject":"Re: git rebase chokes on directory -> symlink -> directory","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-05-10T22:04:18Z","receivedAt":"2007-05-10T22:04:18Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano <junkio@cox.net> wrote:\n>  * git-rebase with -m is dog slow.  There were people who\n>    advocated to make it the default, but they probably are\n>    either working in a very small project, or working on a\n>    filesystem that even git-apply is slow that the speed\n>    difference does not matter to them.\n\nThat would have been me saying make -m default.  Because on git.git\nI don't really see a huge performance difference on my Mac, and the\nbigger projects that I work on are on Cygwin, where *everything*\nis slow as hell.\n\nThe few places there that I do need rebase, I actually also need\nthe rename detection that am -3 or rebase -m would do, so I just\nwind up paying the penalty anyway.  Or really I just get burned\nbecause I run the op without the magic \"do what I really need\"\nflag, and it dies, and I have to reset and start it again, which\njust takes longer than if -3 or -m was the default.\n\nBut that's not the situation everyone else has, so its reasonable\nthat -m ain't the default.  ;-)\n\n-- \nShawn.\n"},{"id":"41810","messageId":"7vmz0cf02i.fsf_-_@assigned-by-dhcp.cox.net","threadId":"8022","inReplyTo":"7vmz0dmb2u.fsf@assigned-by-dhcp.cox.net","subject":"[PATCH] apply: do not get confused by symlinks in the middle","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-11T04:36:53Z","receivedAt":"2007-05-11T04:36:53Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"HPA noticed that git-rebase fails when changes involve symlinks\nin the middle of the hierarchy.  Consider:\n\n * The tree state before the patch is applied has arch/x86_64/boot\n   as a symlink pointing at ../i386/boot/\n\n * The patch tries to remove arch/x86_64/boot symlink, and\n   create bunch of files there: .gitignore, Makefile, etc.\n\ngit-apply tries to be careful while applying patches; it never\ntouches the working tree until it is convinced that the patch\nwould apply cleanly.  One of the check it does is that when it\nknows a path is going to be created by the patch, it runs\nlstat() on the path to make sure it does not exist.\n\nThis leads to a false alarm.  Because we do not touch the\nworking tree before all the check passes, when we try to make\nsure that arch/x86_64/boot/.gitignore does not exist yet, we\nhaven't removed the arch/x86_64/boot symlink.  The lstat() check\nends up seeing arch/i386/boot/.gitignore through the\nyet-to-be-removed symlink, and says \"Hey, you already have a\nfile there, but what you fed me is a patch to create a new\nfile. I am not going to clobber what you have in the working\ntree.\"\n\nWe have similar checks to see a file we are going to modify does\nexist and match the preimage of the diff, which is done by\ndirectly opening and reading the file.\n\nFor a file we are going to delete, we make sure that it does\nexist and matches what is going to be removed (a removal patch\nrecords the full preimage, so we check what you have in your\nworking tree matches it in full -- otherwise we would risk\nlosing your local changes), which again is done by directly\nopening and reading the file.\n\nThese checks need to be adjusted so that they are not fooled by\nsymlinks in the middle.\n\n - To make sure something does not exist, first lstat().  If it\n   does not exist, it does not, so be happy.  If it _does_, we\n   might be getting fooled by a symlink in the middle, so break\n   leading paths and see if there are symlinks involved.  When\n   we are checking for a path a/b/c/d, if any of a, a/b, a/b/c\n   is a symlink, then a/b/c/d does _NOT_ exist, for the purpose\n   of our test.\n\n   This would fix this particular case you saw, and would not\n   add extra overhead in the usual case.\n\n - To make sure something already exists, first lstat().  If it\n   does not exist, barf (up to this, we already do).  Even if it\n   does seem to exist, we might be getting fooled by a symlink\n   in the middle, so make sure leading paths are not symlinks.\n\n   This would make the normal codepath much more expensive for\n   deep trees, which is a bit worrisome.\n\nThis patch implements the first side of the check \"making sure\nit does not exist\".  The latter \"making sure it exists\" check is\nnot done yet, so applying the patch in reverse would still\nfail, but we have to start from somewhere.\n\nSigned-off-by: Junio C Hamano <junkio@cox.net>\n---\n\n * This should help the particular rebase go beyond the 0058\n   patch.  While developing the new t4122 test I noticed that\n   read-tree -m -u (aka git-checkout) seems to have a very\n   similar problem, but I haven't dug into that yet.\n\n builtin-apply.c                 |   69 +++++++++++++++++++++++++++++++++-----\n t/t4122-apply-symlink-inside.sh |   57 ++++++++++++++++++++++++++++++++\n 2 files changed, 117 insertions(+), 9 deletions(-)\n create mode 100755 t/t4122-apply-symlink-inside.sh\n\ndiff --git a/builtin-apply.c b/builtin-apply.c\nindex f94d0db..38d20ef 100644\n--- a/builtin-apply.c\n+++ b/builtin-apply.c\n@@ -2009,6 +2009,63 @@ static int apply_data(struct patch *patch, struct stat *st, struct cache_entry *\n \treturn 0;\n }\n \n+static int has_symlink_component(const char *new_name)\n+{\n+\tchar path[PATH_MAX];\n+\tconst char *sp, *ep;\n+\tchar *dp;\n+\n+\tsp = new_name;\n+\tdp = path;\n+\n+\twhile (1) {\n+\t\tsize_t len;\n+\t\tstruct stat st;\n+\n+\t\tep = strchr(sp, '/');\n+\t\tif (!ep)\n+\t\t\tbreak;\n+\t\tlen = ep - sp;\n+\t\tif (PATH_MAX <= dp + len - path + 2)\n+\t\t\treturn 0; /* new name is longer than that??? */\n+\t\tmemcpy(dp, sp, len);\n+\t\tdp[len] = 0;\n+\n+\t\tif (lstat(path, &st))\n+\t\t\treturn 0; /* why? we already lstat() new_name successfully. */\n+\t\tif (S_ISLNK(st.st_mode))\n+\t\t\treturn 1;\n+\n+\t\tdp[len++] = '/';\n+\t\tdp = dp + len;\n+\t\tsp = ep + 1;\n+\t}\n+\treturn 0;\n+}\n+\n+static int check_to_create_blob(const char *new_name, int ok_if_exists)\n+{\n+\tstruct stat nst;\n+\tif (!lstat(new_name, &nst)) {\n+\t\tif (S_ISDIR(nst.st_mode) || ok_if_exists)\n+\t\t\treturn 0;\n+\t\t/*\n+\t\t * A leading component of new_name might be a symlink\n+\t\t * that is going to be removed with this patch, but\n+\t\t * still pointing at somewhere that has the path.\n+\t\t * In such a case, path \"new_name\" does not exist as\n+\t\t * far as git is concerned.\n+\t\t */\n+\t\tif (has_symlink_component(new_name))\n+\t\t\treturn 0;\n+\n+\t\treturn error(\"%s: already exists in working directory\", new_name);\n+\t}\n+\telse if ((errno != ENOENT) && (errno != ENOTDIR))\n+\t\treturn error(\"%s: %s\", new_name, strerror(errno));\n+\treturn 0;\n+}\n+\n static int check_patch(struct patch *patch, struct patch *prev_patch)\n {\n \tstruct stat st;\n@@ -2095,15 +2152,9 @@ static int check_patch(struct patch *patch, struct patch *prev_patch)\n \t\t    !ok_if_exists)\n \t\t\treturn error(\"%s: already exists in index\", new_name);\n \t\tif (!cached) {\n-\t\t\tstruct stat nst;\n-\t\t\tif (!lstat(new_name, &nst)) {\n-\t\t\t\tif (S_ISDIR(nst.st_mode) || ok_if_exists)\n-\t\t\t\t\t; /* ok */\n-\t\t\t\telse\n-\t\t\t\t\treturn error(\"%s: already exists in working directory\", new_name);\n-\t\t\t}\n-\t\t\telse if ((errno != ENOENT) && (errno != ENOTDIR))\n-\t\t\t\treturn error(\"%s: %s\", new_name, strerror(errno));\n+\t\t\tint err = check_to_create_blob(new_name, ok_if_exists);\n+\t\t\tif (err)\n+\t\t\t\treturn err;\n \t\t}\n \t\tif (!patch->new_mode) {\n \t\t\tif (0 < patch->is_new)\ndiff --git a/t/t4122-apply-symlink-inside.sh b/t/t4122-apply-symlink-inside.sh\nnew file mode 100755\nindex 0000000..37c9a9f\n--- /dev/null\n+++ b/t/t4122-apply-symlink-inside.sh\n@@ -0,0 +1,57 @@\n+#!/bin/sh\n+\n+test_description='apply to deeper directory without getting fooled with symlink'\n+. ./test-lib.sh\n+\n+lecho () {\n+\tfor l_\n+\tdo\n+\t\techo \"$l_\"\n+\tdone\n+}\n+\n+test_expect_success setup '\n+\n+\tmkdir -p arch/i386/boot arch/x86_64 &&\n+\tlecho 1 2 3 4 5 >arch/i386/boot/Makefile &&\n+\tln -s ../i386/boot arch/x86_64/boot &&\n+\tgit add . &&\n+\ttest_tick &&\n+\tgit commit -m initial &&\n+\tgit branch test &&\n+\n+\trm arch/x86_64/boot &&\n+\tmkdir arch/x86_64/boot &&\n+\tlecho 2 3 4 5 6 >arch/x86_64/boot/Makefile &&\n+\tgit add . &&\n+\ttest_tick &&\n+\tgit commit -a -m second &&\n+\n+\tgit format-patch --binary -1 --stdout >test.patch\n+\n+'\n+\n+test_expect_success apply '\n+\n+\tgit checkout test &&\n+\tgit reset --hard && #### checkout seems to be buggy\n+\tgit diff --exit-code test &&\n+\tgit diff --exit-code --cached test &&\n+\tgit apply --index test.patch\n+\n+'\n+\n+test_expect_success 'check result' '\n+\n+\tgit diff --exit-code master &&\n+\tgit diff --exit-code --cached master &&\n+\ttest_tick &&\n+\tgit commit -m replay &&\n+\tT1=$(git rev-parse \"master^{tree}\") &&\n+\tT2=$(git rev-parse \"HEAD^{tree}\") &&\n+\ttest \"z$T1\" = \"z$T2\"\n+\n+'\n+\n+test_done\n+\n-- \n1.5.2.rc3.706.g498a\n"},{"id":"41813","messageId":"7v8xbvew16.fsf@assigned-by-dhcp.cox.net","threadId":"8022","inReplyTo":"20070510220418.GK3141@spearce.org","subject":"Re: git rebase chokes on directory -> symlink -> directory","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-11T06:04:05Z","receivedAt":"2007-05-11T06:04:05Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Shawn O. Pearce\" <spearce@spearce.org> writes:\n\n> Junio C Hamano <junkio@cox.net> wrote:\n>>  * git-rebase with -m is dog slow.  There were people who\n>>    advocated to make it the default, but they probably are\n>>    either working in a very small project, or working on a\n>>    filesystem that even git-apply is slow that the speed\n>>    difference does not matter to them.\n> ...\n> But that's not the situation everyone else has, so its reasonable\n> that -m ain't the default.  ;-)\n\nWell, that is not the conclusion you should be drawing from\nthis. If rebase -m is 10x slower than without -m in cases where\nthe rename handling does not matter, there is something wrong.\n\nAnd what is wrong in this case is that the unpack-trees tree\nmerging code, which is used everywhere in git to do branch\nswitching and merges, is way too inefficient.\n\nWhen merge-recursive is instructed to merge another tree with\nthe current tree using an ancestor, while taking the index into\naccount, it basically does the three-way tree-level merge one\npath at a time, even when subdirectory at quite high level\nmatches identically across three trees.\n\nThe situation is the same for switching branches.  If two\nbranches of the kernel project (22k files spread across 1300\ndirectories) differ at a file at the toplevel (e.g. v2.6.21\nwhich changes only Makefile), we still read the index, the\ncurrent tree, and the other branch, and match all 22k files one\nby one to compute the resulting index entry, by first removing\nthe current index entry and then stuffing the result entry in\nthe index, all the while trashing the cache-tree.  Then we\nrecompute all 1300 tree objects and write them out, even though\nwe should be able to notice that none of the toplevel 17\nsubdirectories have changed, and all we have to do is to rehash\none blob and recompute only one tree object at the toplevel.  We\nboast how lightweight git branches are and how fast switching\nbetween two branches is, but that's a serious lie.  If done\nproperly, we should be able to switch branches in a time roughly\nproportional to the number of paths different between the\nbranches.  Currently, the time is proportional to the size of\nthe tree, no matter how small the change between trees are.\n\ngit-apply, which is used by rebase without -m, is optimized to\nmake it proportional to the size of the change.  It obviously\nknows to only touch the affected paths (because the patch does\nnot talk about unaffected paths) and leave the others intact,\nbut also avoids expensive tree recomputation for unaffected\ndirectories, by properly maintaining the cache-tree data in the\nindex.\n\nIIRC, Linus said unpack-trees was beyond repair several months\nago, and I tend to agree with him.  Currently the first thing\nunpack-trees does is to discard cache-tree from the index,\nbecause the code does not properly invalidate affected paths,\nand it is probably way too cumbersome to add it to various\nplaces the code modifies the index (I haven't looked at it\nrecently, so maybe somebody can try it and prove me wrong).\n\nMy gut feeling is that we may be better off redoing the tree\nlevel merge infrastructure from scratch, and make a new one that\nis optimized for trees with small differences.  There is a\nprototype code called test-para in 'pu' that implements such a\nmulti-tree walk, and also we've had its precursor (by Linus)\ncalled git-merge-tree in 'master' for quite a long time, but\nunfortunately neither has recently seen any activity.\n"},{"id":"41836","messageId":"alpine.LFD.0.98.0705110835230.3986@woody.linux-foundation.org","threadId":"8022","inReplyTo":"7v8xbvew16.fsf@assigned-by-dhcp.cox.net","subject":"Re: git rebase chokes on directory -> symlink -> directory","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-05-11T15:56:24Z","receivedAt":"2007-05-11T15:56:24Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 10 May 2007, Junio C Hamano wrote:\n> \n> And what is wrong in this case is that the unpack-trees tree\n> merging code, which is used everywhere in git to do branch\n> switching and merges, is way too inefficient.\n\nYes, it certainly could be speeded up, but on the other hand:\n\n - it's certainly not really \"horribly bad\" in most normal operations.\n\n   In merging, it tends to be fast enough, and in checkouts the real \n   expense is checking out the tree, and the unpack-trees part really \n   isn't a big deal.\n\n - the only case it shows up is really just when you script things, and \n   compare it to just applying a patch, which is fundamnetally easier.\n\nSo I think the reason smarter tree merging hasn't gotten the love and \nattention to make it really a *lot* faster is simply that it's already \nquite fast enough for most people, and the \"rebase using proper merges\" is \nprobably the only case where you can really see the difference.\n\nI'd certainly love for the tree unpacking to handle all the \"hey, whole \nsub-tree is identical\" cases, but I can also see why it's not getting a \nlot of traction. It just hasn't been painful enough, and we're already too \ndamn fast. \n\nFixing the tree unpacking to do the trees in parallel (so that you don't \nhave to shuffle the arrays and take a huge performance hit there) was \nenough to basically make all normal issues go away. \n\nThat said, wouldn't it potentially be quite easy in \"unpack_trees_rec()\" \nto just notice when all the trees are identical, and just not recurse at \nall in that case (or - alternatively - recurse, but on entry, just exit \nquickly?)\n\n\t\tLinus\n"},{"id":"41845","messageId":"7vfy63b789.fsf@assigned-by-dhcp.cox.net","threadId":"8022","inReplyTo":"alpine.LFD.0.98.0705110835230.3986@woody.linux-foundation.org","subject":"Re: git rebase chokes on directory -> symlink -> directory","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-11T17:28:06Z","receivedAt":"2007-05-11T17:28:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds <torvalds@linux-foundation.org> writes:\n\n> That said, wouldn't it potentially be quite easy in \"unpack_trees_rec()\" \n> to just notice when all the trees are identical, and just not recurse at \n> all in that case (or - alternatively - recurse, but on entry, just exit \n> quickly?)\n\nIn the threeway case, it should be able to notice that the trees\nof the ancestor and the other match, which is the only case we\ncan safely say that the result will be our tree (aka HEAD) and\nwe won't mess with the index nor worry about local modifications\nmade only to the working tree.  The case in which all trees\nmatch, regardless of the number of trees involved, should work\nthe same way.\n\nHowever, in the threeway case, we still need to make sure that\nthe index matches the HEAD even when we know the result will be\ntaken from HEAD, as otherwise we would end up including the\nlocal \"git add\" made earlier in the merge result.  We need to\nmake sure the index matches HEAD for such a subdirectory in that\ncase before skipping it.\n\nWhat is troublesome is that kind of policy logic is not supposed\nto happen in unpack_trees_rec() in the current code structure;\ninstead, that decision is to be made by o->fn().\n\nSo, I am not sure if it is that quite easy.\n"},{"id":"41876","messageId":"7vps569904.fsf@assigned-by-dhcp.cox.net","threadId":"8022","inReplyTo":"46413565.3090503@zytor.com","subject":"Re: git rebase chokes on directory -> symlink -> directory","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-12T00:32:43Z","receivedAt":"2007-05-12T00:32:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"H. Peter Anvin\" <hpa@zytor.com> writes:\n\n> Mine stops already at the directory -> symlink checkin (the above is the\n> symlink -> directory one), but your trick of using \"git checkout\" as a\n> trick to resolve things helped for both... eventually :-/\n\nI've tried to redo your rebase using:\n\n\tapply: do not get confused by symlinks in the middle\n\npatch on top of 'master'.  It successfully run through the end.\nAfter rebasing f1bb07af (\"rebase-1\" in your repository) on to\na989705 (near the tip of Linus), I did\n\n\tgit diff --stat --summary a989705...f1bb07af\n        git diff --stat --summary a989705...HEAD\n\n(that is, \"show me the change since the merge base\") and the\nresults from these two diffs match exactly.\n\nSo I think I can declare victory for now ;-).\n\nHowever.\n\nI usually have \"[apply] whitespace = strip\" in my ~/.gitconfig,\nbut during this verification run, I disabled it to keep rebase\nfrom falling back to 3-way merge using merge-recursive.  If I\nturn it on, rebase still fails and I strongly suspect \"rebase\n-m\" would fail the same way, although I haven't tried it (it\ntakes too much time).\n\nI'll be somewhat busy this weekend, so I would welcome anybody\nelse beating me to fixing the problem in merge-recursive.\n"},{"id":"41877","messageId":"46450BBF.5020900@zytor.com","threadId":"8022","inReplyTo":"7vps569904.fsf@assigned-by-dhcp.cox.net","subject":"Re: git rebase chokes on directory -> symlink -> directory","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2007-05-12T00:35:11Z","receivedAt":"2007-05-12T00:35:11Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Junio C Hamano wrote:\n> \"H. Peter Anvin\" <hpa@zytor.com> writes:\n> \n>> Mine stops already at the directory -> symlink checkin (the above is the\n>> symlink -> directory one), but your trick of using \"git checkout\" as a\n>> trick to resolve things helped for both... eventually :-/\n> \n> I've tried to redo your rebase using:\n> \n> \tapply: do not get confused by symlinks in the middle\n> \n> patch on top of 'master'.  It successfully run through the end.\n> \n> So I think I can declare victory for now ;-).\n> \n\nYAY!  Huge thanks!\n\n\t-hpa\n"},{"id":"42094","messageId":"7v1whkow9z.fsf@assigned-by-dhcp.cox.net","threadId":"8022","inReplyTo":"7vps569904.fsf@assigned-by-dhcp.cox.net","subject":"Re: git rebase chokes on directory -> symlink -> directory","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-14T04:37:44Z","receivedAt":"2007-05-14T04:37:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <junkio@cox.net> writes:\n\n> However.\n>\n> I usually have \"[apply] whitespace = strip\" in my ~/.gitconfig,\n> but during this verification run, I disabled it to keep rebase\n> from falling back to 3-way merge using merge-recursive.  If I\n> turn it on, rebase still fails and I strongly suspect \"rebase\n> -m\" would fail the same way, although I haven't tried it (it\n> takes too much time).\n>\n> I'll be somewhat busy this weekend, so I would welcome anybody\n> else beating me to fixing the problem in merge-recursive.\n\nYuck.  merge-recursive does seem to have problem with D/F\nconflict in general; I suspect this is not limited to cases that\ninvolve symbolic links.\n\nFirst, the setup.\n\n$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/hpa/linux-2.6-newsetup.git/\n$ cd linux-2.6-newsetup.git\n$ git fetch git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/\n$ git branch other b2ad90f4969226fe8cf3edc5330711ed5fc20105\n$ git branch ancestor other^1\n$ git reset --hard ancestor\n$ echo >>Makefile ; git add Makefile ; git commit -m 'change one'\n$ git branch try\n\nTo see that the underlying read-tree is working as expected (and\ndo not have to be debugged), we can first try the usual three-way\nread tree:\n\n$ git read-tree -m -u ancestor HEAD other\n$ git ls-files -u --abbrev arch/x86-64\n\nThis would show...\n\n    120000 ad3f146 3       arch/x86_64/boot\n    100644 495f20c 1       arch/x86_64/boot/.gitignore\n    100644 495f20c 2       arch/x86_64/boot/.gitignore\n    100644 ee6f650 1       arch/x86_64/boot/Makefile\n    100644 ee6f650 2       arch/x86_64/boot/Makefile\n    ...\n\nThe current HEAD (the one that we tagged as 'try') has the\ndirectory arch/x86_64/boot/, but all of its files are unchanged\nfrom the \"common ancestor\", so they all have identical stages 1\nand 2, with stage 3 missing.  The other tree has boot/ as a\nsymlink.  These \"One-side removes other side does not touch\" and\n\"one-side adds\" cases are left unmerged by \"read-tree -m -u\", as\nthat is how merge-recursive can find renames to begin with.\n\nNow we've seen what the read-tree (which is the same machinery\nused as git_merge_trees() in mege-recursive) does with these\nthree trees, let's see how merge-recursive finishes this off:\n\n    $ git reset --hard try\n    $ git merge-recursive ancestor -- HEAD other\n    CONFLICT (directory/file): There is a directory with name arch/x86_64/boot in HEAD. Added arch/x86_64/boot as arch/x86_64/boot~other\n    Removed arch/x86_64/boot/.gitignore\n    Removed arch/x86_64/boot/Makefile\n    Removed arch/x86_64/boot/bootsect.S\n    Removed arch/x86_64/boot/compressed/Makefile\n    Removed arch/x86_64/boot/compressed/head.S\n    Removed arch/x86_64/boot/compressed/misc.c\n    Removed arch/x86_64/boot/compressed/vmlinux.lds\n    Removed arch/x86_64/boot/compressed/vmlinux.scr\n    Removed arch/x86_64/boot/install.sh\n    Removed arch/x86_64/boot/mtools.conf.in\n    Removed arch/x86_64/boot/setup.S\n    Removed arch/x86_64/boot/tools/.gitignore\n    Removed arch/x86_64/boot/tools/build.c\n\nThere is no rename, so rename detection does not interfere, but\nthe D/F conflict detection code in merge-recursive thinks that\narch/x86_64/boot is a directory in one tree (yes, it is true in\nthe original tree, but it goes away as all files under it), and\na non-directory in another.  And instead of replacing the boot/\ndirectory that becomes empty with a new symlink boot/, it\ncreates the boot~funny-name symlink and fails the operation.\n\nWhen it actually is checking out arch/x86_64/boot out of the\nresolved index, it should notice that (1) arch/x86_64/boot\ndirectory is unnecessary to house anything in the resulting\nindex anymore, and that (2) there is no locally created\nuntracked file that is 'precious' [*1*].  Then it can rmdir()\nand create the boot/ symlink in its place.  To fix this, it may\nbe necessary to update its checkout code to perform the \"remove\nfirst then create\" two-pass process git-apply does.\n\nIt is unfortunate that for merge-recursive it is probably too\ncumbersome to always do the right thing, but I think it should\nat least notice that arch/x86_64/boot whose files all disappear\ndoes not conflict with creation of the new symlink.\n"}]}