# Bug in git-diff output 6 messages from 2014-04-01 to 2014-04-03. Participants: rocketscienc01100101 ., Jeff King, Matthieu Moy, Junio C Hamano. Thread: https://gitlist.dev/t/36328 ## rocketscienc01100101 ., 2014-04-01 10:49 Subject: Bug in git-diff output Message-ID: URL: https://gitlist.dev/e/CALgQ2n-vPK6_0LnWA_AAD2GLvepjLN4A3UZFCAWzEp9r_%3DXOVg%40mail.gmail.com ``` I tried to get a diff between HEAD and the current version of my project, so I did "git diff". It's a web project with a CSS file that contains the following CSS rule: a[href^=tel] { color:inherit; text-decoration:none; } Now, whenever I do "git diff", it will always show the a[href^=tel] part and mess up the output, even when I didn't change anything near that line. The problem is easily reproducable in a newly created repository. git --version git version 1.9.1 ``` ## Jeff King, 2014-04-01 11:46 Subject: Re: Bug in git-diff output Message-ID: <20140401114621.GB15549@sigill.intra.peff.net> URL: https://gitlist.dev/e/20140401114621.GB15549%40sigill.intra.peff.net In-Reply-To: ``` On Tue, Apr 01, 2014 at 12:49:00PM +0200, rocketscienc01100101 . wrote: > I tried to get a diff between HEAD and the current version of my > project, so I did "git diff". That actually diffs between the index and the working tree, but if you haven't used "git add" to add any changes, the index content is the same as HEAD. > It's a web project with a CSS file that contains the following CSS rule: > > a[href^=tel] { > color:inherit; > text-decoration:none; > } > > Now, whenever I do "git diff", it will always show the a[href^=tel] > part and mess up the output, even when I didn't change anything near > that line. The problem is easily reproducable in a newly created > repository. I don't understand what you mean here by "mess up the output". Can you show us an example (and tell us what you expected to see)? -Peff ``` ## rocketscienc01100101 ., 2014-04-02 10:59 Subject: Re: Bug in git-diff output Message-ID: URL: https://gitlist.dev/e/CALgQ2n8fNf4kSJhA2w0Us%2BSdDJMRzgeBkEis3Rs%3Dq_Hp9fK4jg%40mail.gmail.com In-Reply-To: ``` On Tue, Apr 1, 2014 at 12:49 PM, rocketscienc01100101 . wrote: > I tried to get a diff between HEAD and the current version of my > project, so I did "git diff". > > It's a web project with a CSS file that contains the following CSS rule: > > a[href^=tel] { > color:inherit; > text-decoration:none; > } > > Now, whenever I do "git diff", it will always show the a[href^=tel] > part and mess up the output, even when I didn't change anything near > that line. The problem is easily reproducable in a newly created > repository. > > git --version > git version 1.9.1 ``` ## rocketscienc01100101 ., 2014-04-02 11:05 Subject: Re: Bug in git-diff output Message-ID: URL: https://gitlist.dev/e/CALgQ2n9VXVpqXe1NQO4%2Bb-Ngmbhxnza52GJqr81t_ubLfjY75g%40mail.gmail.com In-Reply-To: ``` http://i.imgur.com/BoJSjm9.png Here's a screenshot that shows the problem. There's always a misplaced line in the output (most of the time a[href^=tel] { }), no matter where in the file the changes are. Sometimes it's even in the wrong position, above the @@ numbers. I'd naturally expect the a[href^=tel] part to not show up at all unless I make changes there. On Tue, Apr 1, 2014 at 12:49 PM, rocketscienc01100101 . wrote: > I tried to get a diff between HEAD and the current version of my > project, so I did "git diff". > > It's a web project with a CSS file that contains the following CSS rule: > > a[href^=tel] { > color:inherit; > text-decoration:none; > } > > Now, whenever I do "git diff", it will always show the a[href^=tel] > part and mess up the output, even when I didn't change anything near > that line. The problem is easily reproducable in a newly created > repository. > > git --version > git version 1.9.1 ``` ## Matthieu Moy, 2014-04-02 12:09 Subject: Re: Bug in git-diff output Message-ID: URL: https://gitlist.dev/e/vpqmwg4c4q8.fsf%40anie.imag.fr In-Reply-To: ``` "rocketscienc01100101 ." writes: > http://i.imgur.com/BoJSjm9.png > > Here's a screenshot that shows the problem. (better cut-and-paste the text than sending a PNG image) > There's always a misplaced line in the output (most of the time > a[href^=tel] { }), no matter where in the file the changes are. The part after the @@ are ignored by patch tools. They are here just for convenience. They are a guess of what the patch hunk belongs to. For C/Java/Ada/... programs, it's the function name. Git does not know about CSS syntax, so it guesses wrong (last line starting with a letter I guess, not sure exactly what happens when Git doesn't know the syntax). But don't worry, these are juste hints for human, they are harmless. > Sometimes it's even in the wrong position, above the @@ numbers. That is strange. Do you have a way to reproduce this? -- Matthieu Moy http://www-verimag.imag.fr/~moy/ ``` ## Junio C Hamano, 2014-04-03 18:10 Subject: Re: Bug in git-diff output Message-ID: URL: https://gitlist.dev/e/xmqqeh1eqo6s.fsf%40gitster.dls.corp.google.com In-Reply-To: ``` Matthieu Moy writes: > "rocketscienc01100101 ." writes: > >> http://i.imgur.com/BoJSjm9.png >> >> Here's a screenshot that shows the problem. > > (better cut-and-paste the text than sending a PNG image) > >> There's always a misplaced line in the output (most of the time >> a[href^=tel] { }), no matter where in the file the changes are. > > The part after the @@ are ignored by patch tools. They are here just for > convenience. They are a guess of what the patch hunk belongs to. For > C/Java/Ada/... programs, it's the function name. Git does not know about > CSS syntax, so it guesses wrong (last line starting with a letter I > guess, not sure exactly what happens when Git doesn't know the syntax). Ask "git grep -A14 'long def_ff' xdiff/" for details ;-) This was an attempt to be compatible with stock behaviour of GNU diff: a line that begins with an alpha, _ or $. >> Sometimes it's even in the wrong position, above the @@ numbers. > > That is strange. Do you have a way to reproduce this? That indeed is unusual. If the payload that was identified by the find_func function has a funny escape sequence or something, you may get funkiness like that in the output on the terminal, which we may want to take notice and sanitize in xdl_emit_hunk_hdr(), instead of straight memcpy() there, but I do not see how that would be an issue in a css source. ```