{"thread":{"id":"40225","subject":"[BUG] rebase modify/delete conflict prints wrong SHA-1","startedAt":"2015-08-31T00:42:47Z","lastAt":"2015-08-31T00:42:47Z","messageCount":1,"participants":["George Spelvin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"268956","messageId":"20150831004247.17480.qmail@ns.horizon.com","threadId":"40225","inReplyTo":null,"subject":"[BUG] rebase modify/delete conflict prints wrong SHA-1","fromName":"George Spelvin","fromEmail":"linux@horizon.com","sentAt":"2015-08-31T00:42:47Z","receivedAt":"2015-08-31T00:42:47Z","isPatch":false,"sender":{"key":"linux@horizon.com","avatar":null},"body":"I was rebasing my local kernel patches on top of v4.2 (using Debian\ngit_1:2.5.1-1_amd64), and ran into the following when one of the\nfiles I modified got renamed in mainline:\n\nApplying: drivers/ntb/ntb_hw.c: Use prandom_u32_max()\nUsing index info to reconstruct a base tree...\nA       drivers/ntb/ntb_hw.c\nFalling back to patching base and 3-way merge...\nCONFLICT (modify/delete): drivers/ntb/ntb_hw.c deleted in 0ec6a07f518304248dca177405fa607822e4933d and modified in drivers/ntb/ntb_hw.c: Use prandom_u32_max(). Version drivers/ntb/ntb_hw.c: Use prandom_u32_max() of drivers/ntb/ntb_hw.c left in tree.\nFailed to merge in the changes.\nPatch failed at 0037 drivers/ntb/ntb_hw.c: Use prandom_u32_max()\nThe copy of the patch that failed is found in:\n   /usr/src/linux/.git/rebase-apply/patch\n\nThe problem is that 0ec6a07f518304248dca177405fa607822e4933d is *my* patch.\nAnd it's not the conflicting patch, either, it's some nearby patch!\n\nThe file was renamed in ec110bc7cc48d7806c9b65094e6afb19452d458f\n(\"NTB: Move files in preparation for NTB abstraction\"),\nwhich you can find in 4.2-rc1.\n\nIt appears that there's a glitch in printing the SHA-1 in this case.\n\n\nI tried to reproduce it with the trivial case: create an initial\ncommit with one file, delete it in one branch, modify it in another,\nand then rebase the second on top of the first.\n\ngit rebase printed the right SHA-1.\n\n\nBut if I have two commits on each branch, I get something similar:\n\ngit init foo\ncd foo\necho foo > foo\necho bar > bar\ngit add foo bar\ngit commit -m \"Initial commit\"\ngit rm foo\ngit commit -m \"Delete foo\"\ngit rm bar\ngit commit -m \"Delete bar\"\ngit checkout -b branch HEAD^^\necho baz >> foo\ngit commit -m \"Edit foo\" foo\necho baz >> bar\ngit commit -m \"Edit bar\" bar\ngit rebase master\n\nFirst, rewinding head to replay your work on top of it...\nApplying: Edit foo\nUsing index info to reconstruct a base tree...\nA       foo\nFalling back to patching base and 3-way merge...\nCONFLICT (modify/delete): foo deleted in 52e1cece1e48dc21b317d4bd671fa171c3a7abd3 and modified in Edit foo. Version Edit foo of foo left in tree.\nFailed to merge in the changes.\nPatch failed at 0001 Edit foo\nThe copy of the patch that failed is found in:\n   /tmp/foo/.git/rebase-apply/patch\n\nFor me, commit 52e1cece is the patch that removes bar, not foo:\n\n$ git show 52e1cece\ncommit 52e1cece1e48dc21b317d4bd671fa171c3a7abd3\nAuthor: George Spelvin <linux@horizon.com>\nDate:   Sun Aug 30 18:59:09 2015 -0400\n\n    Delete bar\n\ndiff --git a/bar b/bar\ndeleted file mode 100644\nindex 5716ca5..0000000\n--- a/bar\n+++ /dev/null\n@@ -1 +0,0 @@\n-bar\n"}]}