{"thread":{"id":"36328","subject":"Bug in git-diff output","startedAt":"2014-04-01T10:49:00Z","lastAt":"2014-04-03T18:10:19Z","messageCount":6,"participants":["rocketscienc01100101 .","Jeff King","Matthieu Moy","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"238194","messageId":"CALgQ2n-vPK6_0LnWA_AAD2GLvepjLN4A3UZFCAWzEp9r_=XOVg@mail.gmail.com","threadId":"36328","inReplyTo":null,"subject":"Bug in git-diff output","fromName":"rocketscienc01100101 .","fromEmail":"rocketscienc01100101@gmail.com","sentAt":"2014-04-01T10:49:00Z","receivedAt":"2014-04-01T10:49:00Z","isPatch":false,"sender":{"key":"rocketscienc01100101@gmail.com","avatar":null},"body":"I tried to get a diff between HEAD and the current version of my\nproject, so I did \"git diff\".\n\nIt's a web project with a CSS file that contains the following CSS rule:\n\na[href^=tel] {\n color:inherit;\n text-decoration:none;\n}\n\nNow, whenever I do \"git diff\", it will always show the a[href^=tel]\npart and mess up the output, even when I didn't change anything near\nthat line. The problem is easily reproducable in a newly created\nrepository.\n\ngit --version\ngit version 1.9.1\n"},{"id":"238198","messageId":"20140401114621.GB15549@sigill.intra.peff.net","threadId":"36328","inReplyTo":"CALgQ2n-vPK6_0LnWA_AAD2GLvepjLN4A3UZFCAWzEp9r_=XOVg@mail.gmail.com","subject":"Re: Bug in git-diff output","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-04-01T11:46:22Z","receivedAt":"2014-04-01T11:46:22Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Apr 01, 2014 at 12:49:00PM +0200, rocketscienc01100101 . wrote:\n\n> I tried to get a diff between HEAD and the current version of my\n> project, so I did \"git diff\".\n\nThat actually diffs between the index and the working tree, but if you\nhaven't used \"git add\" to add any changes, the index content is the same\nas HEAD.\n\n> It's a web project with a CSS file that contains the following CSS rule:\n> \n> a[href^=tel] {\n> color:inherit;\n> text-decoration:none;\n> }\n> \n> Now, whenever I do \"git diff\", it will always show the a[href^=tel]\n> part and mess up the output, even when I didn't change anything near\n> that line. The problem is easily reproducable in a newly created\n> repository.\n\nI don't understand what you mean here by \"mess up the output\". Can you\nshow us an example (and tell us what you expected to see)?\n\n-Peff\n"},{"id":"238289","messageId":"CALgQ2n8fNf4kSJhA2w0Us+SdDJMRzgeBkEis3Rs=q_Hp9fK4jg@mail.gmail.com","threadId":"36328","inReplyTo":"CALgQ2n-vPK6_0LnWA_AAD2GLvepjLN4A3UZFCAWzEp9r_=XOVg@mail.gmail.com","subject":"Re: Bug in git-diff output","fromName":"rocketscienc01100101 .","fromEmail":"rocketscienc01100101@gmail.com","sentAt":"2014-04-02T10:59:43Z","receivedAt":"2014-04-02T10:59:43Z","isPatch":false,"sender":{"key":"rocketscienc01100101@gmail.com","avatar":null},"body":"On Tue, Apr 1, 2014 at 12:49 PM, rocketscienc01100101 .\n wrote:\n> I tried to get a diff between HEAD and the current version of my\n> project, so I did \"git diff\".\n>\n> It's a web project with a CSS file that contains the following CSS rule:\n>\n> a[href^=tel] {\n> color:inherit;\n> text-decoration:none;\n> }\n>\n> Now, whenever I do \"git diff\", it will always show the a[href^=tel]\n> part and mess up the output, even when I didn't change anything near\n> that line. The problem is easily reproducable in a newly created\n> repository.\n>\n> git --version\n> git version 1.9.1\n"},{"id":"238328","messageId":"CALgQ2n9VXVpqXe1NQO4+b-Ngmbhxnza52GJqr81t_ubLfjY75g@mail.gmail.com","threadId":"36328","inReplyTo":"CALgQ2n-vPK6_0LnWA_AAD2GLvepjLN4A3UZFCAWzEp9r_=XOVg@mail.gmail.com","subject":"Re: Bug in git-diff output","fromName":"rocketscienc01100101 .","fromEmail":"rocketscienc01100101@gmail.com","sentAt":"2014-04-02T11:05:36Z","receivedAt":"2014-04-02T11:05:36Z","isPatch":false,"sender":{"key":"rocketscienc01100101@gmail.com","avatar":null},"body":"http://i.imgur.com/BoJSjm9.png\n\nHere's a screenshot that shows the problem. There's always a misplaced\nline in the output (most of the time a[href^=tel] { }), no matter\nwhere in the file the changes are.\nSometimes it's even in the wrong position, above the @@ numbers.\n\nI'd naturally expect the a[href^=tel] part to not show up at all\nunless I make changes there.\n\nOn Tue, Apr 1, 2014 at 12:49 PM, rocketscienc01100101 .\n wrote:\n> I tried to get a diff between HEAD and the current version of my\n> project, so I did \"git diff\".\n>\n> It's a web project with a CSS file that contains the following CSS rule:\n>\n> a[href^=tel] {\n> color:inherit;\n> text-decoration:none;\n> }\n>\n> Now, whenever I do \"git diff\", it will always show the a[href^=tel]\n> part and mess up the output, even when I didn't change anything near\n> that line. The problem is easily reproducable in a newly created\n> repository.\n>\n> git --version\n> git version 1.9.1\n"},{"id":"238336","messageId":"vpqmwg4c4q8.fsf@anie.imag.fr","threadId":"36328","inReplyTo":"CALgQ2n9VXVpqXe1NQO4+b-Ngmbhxnza52GJqr81t_ubLfjY75g@mail.gmail.com","subject":"Re: Bug in git-diff output","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2014-04-02T12:09:51Z","receivedAt":"2014-04-02T12:09:51Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"\"rocketscienc01100101 .\" writes:\n\n> http://i.imgur.com/BoJSjm9.png\n>\n> Here's a screenshot that shows the problem.\n\n(better cut-and-paste the text than sending a PNG image)\n\n> There's always a misplaced line in the output (most of the time\n> a[href^=tel] { }), no matter where in the file the changes are.\n\nThe part after the @@ are ignored by patch tools. They are here just for\nconvenience. They are a guess of what the patch hunk belongs to. For\nC/Java/Ada/... programs, it's the function name. Git does not know about\nCSS syntax, so it guesses wrong (last line starting with a letter I\nguess, not sure exactly what happens when Git doesn't know the syntax).\n\nBut don't worry, these are juste hints for human, they are harmless.\n\n> Sometimes it's even in the wrong position, above the @@ numbers.\n\nThat is strange. Do you have a way to reproduce this?\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"238356","messageId":"xmqqeh1eqo6s.fsf@gitster.dls.corp.google.com","threadId":"36328","inReplyTo":"vpqmwg4c4q8.fsf@anie.imag.fr","subject":"Re: Bug in git-diff output","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-04-03T18:10:19Z","receivedAt":"2014-04-03T18:10:19Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\n> \"rocketscienc01100101 .\" writes:\n>\n>> http://i.imgur.com/BoJSjm9.png\n>>\n>> Here's a screenshot that shows the problem.\n>\n> (better cut-and-paste the text than sending a PNG image)\n>\n>> There's always a misplaced line in the output (most of the time\n>> a[href^=tel] { }), no matter where in the file the changes are.\n>\n> The part after the @@ are ignored by patch tools. They are here just for\n> convenience. They are a guess of what the patch hunk belongs to. For\n> C/Java/Ada/... programs, it's the function name. Git does not know about\n> CSS syntax, so it guesses wrong (last line starting with a letter I\n> guess, not sure exactly what happens when Git doesn't know the syntax).\n\nAsk \"git grep -A14 'long def_ff' xdiff/\" for details ;-)\n\nThis was an attempt to be compatible with stock behaviour of GNU\ndiff: a line that begins with an alpha, _ or $.\n\n>> Sometimes it's even in the wrong position, above the @@ numbers.\n>\n> That is strange. Do you have a way to reproduce this?\n\nThat indeed is unusual. If the payload that was identified by the\nfind_func function has a funny escape sequence or something, you may\nget funkiness like that in the output on the terminal, which we may\nwant to take notice and sanitize in xdl_emit_hunk_hdr(), instead of\nstraight memcpy() there, but I do not see how that would be an issue\nin a css source.\n"}]}