4 ms·

`git` generally doesn't work with lines of text. Mostly it works with opaque file blobs and directory trees. `git diff` and `git merge` work with lines of text

`git` generally doesn't work with lines of text. Mostly it works with opaque file blobs and directory trees. `git diff` and `git merge` work with lines of text by default - but they don't have to. You can supply your own `diff` and `merge` tools with the `difftool.*` and `mergetool.*` config options, try them out with `git-difftool` and `git-mergetool` commands, and set the default with the `git.diff` and `git.merge` config options. If someone wanted to create AST-based diff and merge tools for a given language, they could be plugged right into the existing `git` infrastructure and it would work with them absolutely fine.

bspammer 5y ago
This feature is useful in so many different places. I use it to diff small encrypted files in my repo - just add `gpg -d` as a diff configuration and now I can use git log, diff etc in a meaningful way with binary files. I've heard of people using it with pdfs as well - a pdf to html converter lets you get a good idea of what changed in the document.
colonwqbang 5y ago
Yes, I think this article is coming at it from the wrong end. Git is hardly the problem here, nor is it going to provide the solution. The problem seems to be that we are lacking the format and the toolchain to manipulate it, and that is not the fault of git. What is the state of the art in this area? Does somebody know of a viable format and toolchain, or any interesting projects looking to build them?
tyleo 5y ago
I believe that semantic merge does something like this: https://www.semanticmerge.com/ https://www.semanticmerge.com/
- paul_h 5y ago
  Came to link to that :)
kapep 5y ago
> If someone wanted to create AST-based diff and merge tools for a given language, they could be plugged right into the existing `git` infrastructure and it would work with them absolutely fine. There's a lot tooling in the Eclipse modelling ecosystem which could be easily used for this. Storing XML-based models in git is no problem and there's tooling for diffing and merging models via a GUI or programmatically. Combined with the fact that xtext DSLs use EMF models to represent ASTs, it wouldn't be too hard to glue together an AST-based a diff/merge tool for an xtext DSL.
dTal 5y ago
What if generating a diff is nontrivial? Say you rename an identifier. That might be a single command in an IDE. A sufficiently high-level "diff" format could easily capture that intent. But working backwards from hundreds of touched lines across many files to deduce that single semantic edit is not trivial. Git assumes that arbitrary diffs can be deduced from "before" and "after" files, but this isn't the case - it may be that you'd rather generate the new file from the diff!
rileymat2 5y ago
> `git` generally doesn't work with lines of text. Mostly it works with opaque file blobs and directory trees. I am not sure this is true. In the past it gave me problems with line ending normalization between windows/mac/linux, in and out. In those cases it definitely had a lines of text view of things.
- ajanuary 5y ago
  Git is delegating to the diff to work out how to merge the blobs. It's the diff that is having trouble with the line endings.
  - rileymat2 5y ago
    No, in the past, git would change line endings. A check in on one machine and a check out on another machine would give different files.
- Ajedi32 5y ago
  It is generally true, but yes; automatic line ending conversion is an exception. You can turn it off with `git config --global core.autocrlf false`, though be aware that can cause issues if you have developers on different operating systems creating and committing files with different line endings.
indentit 5y ago
I guess this is what diffsitter[1] is for. [1]: https://news.ycombinator.com/item?id=27875333 https://news.ycombinator.com/item?id=27875333
kmeisthax 5y ago
Indeed. The Composer merge driver is critical for being able to work with modern PHP frameworks without tearing your hear out on every merge. Merge drivers are Git's most powerful and least known feature, and I really wish they were more common.

bspammer 5y ago

This feature is useful in so many different places. I use it to diff small encrypted files in my repo - just add `gpg -d` as a diff configuration and now I can use git log, diff etc in a meaningful way with binary files. I've heard of people using it with pdfs as well - a pdf to html converter lets you get a good idea of what changed in the document.

colonwqbang 5y ago

Yes, I think this article is coming at it from the wrong end. Git is hardly the problem here, nor is it going to provide the solution. The problem seems to be that we are lacking the format and the toolchain to manipulate it, and that is not the fault of git. What is the state of the art in this area? Does somebody know of a viable format and toolchain, or any interesting projects looking to build them?

tyleo 5y ago

I believe that semantic merge does something like this: https://www.semanticmerge.com/ https://www.semanticmerge.com/

paul_h 5y ago
Came to link to that :)

kapep 5y ago

> If someone wanted to create AST-based diff and merge tools for a given language, they could be plugged right into the existing `git` infrastructure and it would work with them absolutely fine. There's a lot tooling in the Eclipse modelling ecosystem which could be easily used for this. Storing XML-based models in git is no problem and there's tooling for diffing and merging models via a GUI or programmatically. Combined with the fact that xtext DSLs use EMF models to represent ASTs, it wouldn't be too hard to glue together an AST-based a diff/merge tool for an xtext DSL.

dTal 5y ago

What if generating a diff is nontrivial? Say you rename an identifier. That might be a single command in an IDE. A sufficiently high-level "diff" format could easily capture that intent. But working backwards from hundreds of touched lines across many files to deduce that single semantic edit is not trivial. Git assumes that arbitrary diffs can be deduced from "before" and "after" files, but this isn't the case - it may be that you'd rather generate the new file from the diff!

rileymat2 5y ago

> `git` generally doesn't work with lines of text. Mostly it works with opaque file blobs and directory trees. I am not sure this is true. In the past it gave me problems with line ending normalization between windows/mac/linux, in and out. In those cases it definitely had a lines of text view of things.

ajanuary 5y ago
Git is delegating to the diff to work out how to merge the blobs. It's the diff that is having trouble with the line endings.
- rileymat2 5y ago
  No, in the past, git would change line endings. A check in on one machine and a check out on another machine would give different files.
Ajedi32 5y ago
It is generally true, but yes; automatic line ending conversion is an exception. You can turn it off with `git config --global core.autocrlf false`, though be aware that can cause issues if you have developers on different operating systems creating and committing files with different line endings.

indentit 5y ago

I guess this is what diffsitter[1] is for. [1]: https://news.ycombinator.com/item?id=27875333 https://news.ycombinator.com/item?id=27875333

kmeisthax 5y ago

Indeed. The Composer merge driver is critical for being able to work with modern PHP frameworks without tearing your hear out on every merge. Merge drivers are Git's most powerful and least known feature, and I really wish they were more common.