4

Here is some parts from a diff file generated using git diff HEAD.

@@ -261,6 +261,13 @@ public class JSONServiceAction extends JSONAction {
                            return new double[0][0];
                    }
            }
+               /*
+                * Some changes made...
+                */
            else if (typeNameOrClassDescriptor.equals("[[F")) {
                    String[] values = request.getParameterValues(parameter);

@@ -587,4 +594,4 @@ public class JSONServiceAction extends JSONAction {
    private Map<String, Object[]> _methodCache =
            new HashMap<String, Object[]>();

-}
\ No newline at end of file
+}

I have two problems with this:

  1. look at the hunk header lines, there is a public class ... after the @@. So git diff is putting the code block name (here is a class defination) in the hunk header. Why is git diff doing this? Can I ask git diff not to put that part in the hunk header?
  2. Look at the second hunk part. It shows the last few lines of the class file, which is not modified at all. Why is git diff including this part in the diff file? Can I avoid it? (Actually the only modified part of this class is in the first hunk area, where I added three lines of comments before the else if)

I checked the git diff man page, but now I am still confusing because I don't quite understand some part of the manual; I also checked some related questions that SO recommended, but they are all about "HOW TO SHOW A METHOD NAME HERE INSTEAD OF A CLASS NAME", like this: Is there a way to ask git diff to show the method name instead of the class name?.

If there is not a method to disable the custom hunk head, please tell me as well so that I can try with some scripting.

Update: The reason why I want the hunk description off

In my job, the benchmark test, one step in the build script is to automatically collect the codebase info of the source folder if it is a svn working copy -- the info includes a diff file. Now we want it to support git. Of course we will save a pure-git diff file, however, we have to generate a svn-compitable diff at the same time. This is because the developers use git and the QAs (testers) use svn (the manager migrates reviewed code only from git to svn).

For the SVN client, (SmartSVN, which is not smart at all) in my work environment, it doesn't matter whether the diff file has certain SVN information lines. It does matter that the file path doesn't have a prefix, and the hunk header doesn't have a description...

Community
  • 1
  • 1
Dante WWWW
  • 2,729
  • 1
  • 17
  • 33

3 Answers3

2
  1. Git's putting those block names to make it easier for humans to determine which part of the file a given patch is affecting. In case of C it show a first line of a function definition, which is really useful. Apparently it's slightly less informative in case of Java. Why does it trouble you?
  2. You have added or removed a newline character at the end of the file. Git treats it as a difference. Hence it's listed in the diff.
Jan
  • 11,636
  • 38
  • 47
  • Because it is preventing a git generated diff file from being applied to a svn working copy. I have managed to let `git-diff` generate a diff of a xml file that SmartSVN can apply, however when it came to a java file, SmartSVN treats the custom hunk header as corrupted. – Dante WWWW Dec 23 '11 at 09:44
  • @coolcfan, how did you try to apply the patch? By using traditional `patch` utility you shouldn't have any problems. `patch -p1 -i git-diff-generated-this.patch`. – Jan Dec 23 '11 at 09:46
  • Also see [here](http://stackoverflow.com/questions/708202/git-format-patch-to-be-svn-compatible) for a discussion on svn-compatible diff format. It may not apply directly since you didn't indicate you are using git-svn. – djs Dec 23 '11 at 09:59
  • 3
    @coolcfan: The hunk header is ignored by both the canonical patch utility and `git apply`; it's a shame your tools have broken from convention. – Cascabel Dec 23 '11 at 13:38
  • @Jefromi Yes, I think so. The SmartSVN is a shame. – Dante WWWW Dec 23 '11 at 16:13
  • @djs For the SVN client, SmartSVN (which is not smart at all) in my work environment, it doesn't matter whether the diff file has certain SVN information lines. It does matter that the file path doesn't have a prefix, and the hunk header doesn't have a description... – Dante WWWW Dec 23 '11 at 16:19
  • Check this: gist.github.com/1520442 Could it safely delete the hunk header additional info? – Dante WWWW Dec 26 '11 at 03:25
1

For your point 2, you had a file with no newline at the end committed. Your current version has a newline at the end (a lot of editors add one for you). That's what the diff is showing.

$ git init
Initialized empty Git repository in ...
$ echo -n hello > file
$ git add file ; git commit -m test
[master (root-commit) 846c33e] test
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 file
$ echo hello > file
$ git diff
showing.diff --git a/file b/file
index b6fc4c6..ce01362 100644
--- a/file
+++ b/file
@@ -1 +1 @@
-hello
\ No newline at end of file
+hello

For your 1., see: Git format-patch to be svn compatible?

Community
  • 1
  • 1
Mat
  • 202,337
  • 40
  • 393
  • 406
  • Thanks for answering the second question. For the reason of the first problem, check my comment under Jan's answer. – Dante WWWW Dec 23 '11 at 09:44
  • Ah, ok. That's already been asked . There's a nasty `sed` converter expression in one of the answers there. – Mat Dec 23 '11 at 09:50
1

  1. As mentioned, the hunk header is for convenience. If you want to change what it displays, see the git attributes manpage section on defining a custom hunk-header and see an example for python here. If you define the regex so it won't match, then you won't get the hunk header. Before you do this, I'd suggest making sure you have a good reason to do so. It shouldn't harm anything, and if you're parsing the diff yourself, you ought to be capable of accepting a standard git diff.

  2. The \ No newline at end of file indicator is standard notation in a unified diff file and is used to indicate exactly that.

Community
  • 1
  • 1
djs
  • 4,626
  • 2
  • 28
  • 38