Bug 1211062 - interdiff has problems with newly added files
Summary: interdiff has problems with newly added files
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: patchutils
Version: 21
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Tim Waugh
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-04-12 16:15 UTC by Ulrich Drepper
Modified: 2015-07-29 01:52 UTC (History)
1 user (show)

Fixed In Version: patchutils-0.3.4-2.fc21
Clone Of:
Environment:
Last Closed: 2015-07-29 01:52:26 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
don't feed non-diff lines to patch (649 bytes, patch)
2015-04-13 02:33 UTC, Ulrich Drepper
no flags Details | Diff

Description Ulrich Drepper 2015-04-12 16:15:07 UTC
Description of problem:
In Fedora 21 interdiff does not work at all.  Something is wrong with the way it handles the various files it creates.

Version-Release number of selected component (if applicable):
patchutils-0.3.3-6.fc21.x86_64

How reproducible:
always

Steps to Reproduce:
1.Run these commands:

mkdir testdir
cd testdir
echo aaa > aaa
cp aaa aaa.old
echo bbb >> aaa
diff -u aaa.old aaa > D1
cp aaa aaa.old2
echo ccc >> aaa
diff -u aaa.old2 aaa > D2
interdiff D1 D2

Actual results:
The program unexpected says:
Reversed (or previously applied) patch detected!  Assume -R? [n]

In some other situations I have seen it complaining about temp files already existing, like:

The next patch would create the file /tmp/interdiff-1.hrRgt3,
which already exists!  Assume -R? [n]


Expected results:
Just the inter-diff output

Additional info:

Comment 1 Tim Waugh 2015-04-12 22:27:46 UTC
D1 and D2 have different bases: aaa.old, and aaa.old2. Interdiff is for comparing alternative patches made against the same base, e.g. the way kernel pre-patches are done.

Compare with:

$ diff -u aaa.old aaa > D3
$ interdiff D1 D3
diff -u aaa aaa
--- aaa	2015-04-12 23:22:34.092443904 +0100
+++ aaa	2015-04-12 23:22:48.231408389 +0100
@@ -2,0 +3 @@
+ccc

The difference between the state at the point you made D1 and the state at the point you made D2 is contained in D2.

Comment 2 Ulrich Drepper 2015-04-13 02:17:06 UTC
Uhm, forget the previous comment, this was an ill-fated attempt to simplify the problem description.  But I created files which cannot be handled so ignore that.  I change the bug description accordingly.  The error message is real, though.

Create one file which looks like this:

cat >>EOF > FILE


diff --git a/elf/tst-audit11mod1.c b/elf/tst-audit11mod1.c
new file mode 100644
index 0000000..f0c06ab
--- /dev/null
+++ b/elf/tst-audit11mod1.c
@@ -0,0 +1,6 @@
+extern int f2 (void);
+int
+f1 (void)
+{
+  return f2 ();
+}
diff --git a/elf/tst-audit11mod2.c b/elf/tst-audit11mod2.c
new file mode 100644
index 0000000..cd3c9b1
--- /dev/null
+++ b/elf/tst-audit11mod2.c
@@ -0,0 +1,5 @@
+int
+f2 (void)
+{
+  return 42;
+}
EOF

Now run interdiff on this file, passing the same file name twice.  This does not reflect the real situation in my case.  The files I was looking at had actual differences but the parts above were identical.

When I run

interdiff FILE FILE

I see:

The next patch would create the file /tmp/interdiff-1.VdtTWa,
which already exists!  Assume -R? [n] 


The output should of course just be empty.

If you remove one of the patches in the file the problem goes away.

Comment 3 Ulrich Drepper 2015-04-13 02:24:10 UTC
The problem is the handling of the lines git (and other programs) add.  It boils down to something like this:

touch aaa
cat <<EOF >P
--- aaa
+++ aaa
@@ -0,0 +1 @@
+aaa
diff --git a/elf/tst-audit11mod2.c b/elf/tst-audit11mod2.c
new file mode 100644
EOF
patch -sp0 aaa < P

This creates the error:

The next patch would create the file aaa,


Patch recognizes those magic lines generated by git.

I think I know how to fix it, might submit a patch shortly.

Comment 4 Ulrich Drepper 2015-04-13 02:33:51 UTC
Created attachment 1013787 [details]
don't feed non-diff lines to patch

This patch works around the problem with git-induced lines.  Perhaps it's possible to avoid writing all non-diff lines but I am cautious and reject only those I know can happen and shouldn't be part of the patch.

Comment 5 Tim Waugh 2015-04-13 10:20:28 UTC
I see, yes. Thanks for the patch. I've applied it upstream.
https://github.com/twaugh/patchutils/commit/67045cecd445de148a48d1e2b15f614a3570d523

Comment 6 Fedora Update System 2015-04-20 20:31:14 UTC
patchutils-0.3.4-1.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/patchutils-0.3.4-1.fc22

Comment 7 Fedora Update System 2015-04-20 20:42:28 UTC
patchutils-0.3.4-1.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/patchutils-0.3.4-1.fc21

Comment 8 Fedora Update System 2015-04-22 22:47:14 UTC
Package patchutils-0.3.4-1.fc22:
* should fix your issue,
* was pushed to the Fedora 22 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing patchutils-0.3.4-1.fc22'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-6614/patchutils-0.3.4-1.fc22
then log in and leave karma (feedback).

Comment 9 Fedora Update System 2015-07-29 01:52:26 UTC
patchutils-0.3.4-2.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.