git/list[1] front-page[2] threads[3] people[4] search[5] about
 

[BUG] rebase modify/delete conflict prints wrong SHA-1

From
GSGeorge Spelvin <linux@horizon.com>
Date
Aug 31, 2015, 00:42 UTC
Message-ID
<20150831004247.17480.qmail@ns.horizon.com>

I was rebasing my local kernel patches on top of v4.2 (using Debian git_1:2.5.1-1_amd64), and ran into the following when one of the files I modified got renamed in mainline:

Applying: drivers/ntb/ntb_hw.c: Use prandom_u32_max()
Using index info to reconstruct a base tree...
A       drivers/ntb/ntb_hw.c
Falling back to patching base and 3-way merge...
CONFLICT (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.
Failed to merge in the changes.
Patch failed at 0037 drivers/ntb/ntb_hw.c: Use prandom_u32_max()
The copy of the patch that failed is found in:
   /usr/src/linux/.git/rebase-apply/patch

The problem is that 0ec6a07f518304248dca177405fa607822e4933d is *my* patch. And it's not the conflicting patch, either, it's some nearby patch!

The file was renamed in ec110bc7cc48d7806c9b65094e6afb19452d458f ("NTB: Move files in preparation for NTB abstraction"), which you can find in 4.2-rc1.

It appears that there's a glitch in printing the SHA-1 in this case.

I tried to reproduce it with the trivial case: create an initial commit with one file, delete it in one branch, modify it in another, and then rebase the second on top of the first.

git rebase printed the right SHA-1.
But if I have two commits on each branch, I get something similar:

git init foo cd foo echo foo > foo echo bar > bar git add foo bar git commit -m "Initial commit" git rm foo git commit -m "Delete foo" git rm bar git commit -m "Delete bar" git checkout -b branch HEAD^^ echo baz >> foo git commit -m "Edit foo" foo echo baz >> bar git commit -m "Edit bar" bar git rebase master

First, rewinding head to replay your work on top of it...
Applying: Edit foo
Using index info to reconstruct a base tree...
A       foo
Falling back to patching base and 3-way merge...
CONFLICT (modify/delete): foo deleted in 52e1cece1e48dc21b317d4bd671fa171c3a7abd3 and modified in Edit foo. Version Edit foo of foo left in tree.
Failed to merge in the changes.
Patch failed at 0001 Edit foo
The copy of the patch that failed is found in:
   /tmp/foo/.git/rebase-apply/patch
For me, commit 52e1cece is the patch that removes bar, not foo:
$ git show 52e1cece
commit 52e1cece1e48dc21b317d4bd671fa171c3a7abd3
Author: George Spelvin <linux@horizon.com>
Date:   Sun Aug 30 18:59:09 2015 -0400
    Delete bar
diff --git a/bar b/bar
deleted file mode 100644
index 5716ca5..0000000
--- a/bar
+++ /dev/null
@@ -1 +0,0 @@
-bar
Message 1 of 1 in “[BUG] rebase modify/delete conflict prints wrong SHA-1”
  1. George SpelvinAug 31, 2015

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.