The problem occurs when trying to diff blocks with same structure commonly appears in html/css for me. Example: Initial commit
Now lets add new param to "someblock" and new class "someotherblock". result
Expected result:
1 1 .someblock
2 2 height:100%;
3+ width:100%;
3 4 }
5+.someotherblock{
6+ height:100%;
7+}
Is there any way to make git undestand "logic" of the changes?
These changes mean that metadata about your file changed, however the content of your file did not. If you're working in a group, this may start to intefere with pushes or just add noise to your commits.
The git diff command returns a list of all the changes in all the files between our last commit and our current repository. If you want to retrieve the changes made to a specific file in a repository, you can specify that file as a third parameter.
Your file is already staged to be committed. You can show it's diff using the --cached option of git. To unstage it, just do what git status suggests in it's output ;) You can check The Git Index For more info.
So, putting this together with what you cited above, the files you are seeing with R100 status mean that they were moved, and that Git found a 100% match between that file and some other previously named file.
It's important to realize that Git does not, and really can not, show you exactly what you did. (Maybe you added the braces first, then added the contents, in that order, in which case to show you what you did it would have to say "first add both braces, then add the contents in between".) Instead, Git simply produces a minimal1 set of instructions that tell a computer how to change "what was there before" to "what should be there now".
The Git programmers try to make the "understandable to computer" instructions somewhat sensible to humans as well, but the answer to this:
Is there any way to make git understand "logic" of the changes?
is "no".
The patience diff (see Gira's answer) can help for some cases, particularly those where Git synchronizes on lines consisting solely of open or close braces and the like.
Git 2.9 added a so-called "compaction heuristic" (described rather lightly here) but it requires a blank line above the changed region. That phrase, "a blank line above", means a blank line, and above: the compaction heuristic doesn't believe the top of a file suffices (although in my opinion it should believe this). The compaction heuristic makes a bigger difference, although for me, the idea of twisting the source just to make the VCS display better diffs is ... annoying, at least.
1"Minimal" in the sense of the fewest possible "delete X" and "add Y" instructions. Git does not take into account the lengths of X and Y, which are typically lines, although Git does have word-oriented diff as well. Ties—where Git could say "delete four lines here and add four there" and move the four around, up or down, get broken in favor of "furthest down" due to the algorithm used, which is why the compaction heuristic only tries to shift up.
git diff --histogram
is what you're looking for. It will display changes like this in a more human-readable way. It solves the problem of git diff showing brackets (curly braces) "wrong".
See What's the difference between `git diff --patience` and `git diff --histogram`?
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With