Hacker News Reader

Comment by Karellen | Hacker News Reader

`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.

View on HN

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.

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!

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

Came to link to that :)

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?

I guess this is what diffsitter[1] is for.

[1]: https://news.ycombinator.com/item?id=27875333

> 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.

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.

> `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.

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.

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.

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.

Reply on news.ycombinator.com