3 ms·

It is funny, one of the things that has bothered me for quite a while is that diffs don’t understand code. For example if I add an additional usage to a global

It is funny, one of the things that has bothered me for quite a while is that diffs don’t understand code. For example if I add an additional usage to a global variable to a file, while someone else renames it in other files, git happily merges with no conflict. Tighter language integration can help with that.

k1ll3r 5y ago
you can write a diff tool that talks to an LSP server
nick__m 5y ago
This tight integration between language and general purpose tool is a nice idea with a terrible price. It would make tools a lot harder to develop and they would be a lot slower as they now have to perform significantly more work.
rfw300 5y ago
That strikes me as outside the scope of a feasible version control tool (and is probably undecidable in most cases). Seems like you’d be much better off handling that with a test suite and CI.
- rileymat2 5y ago
  I kind of agree, but if you have a very tight coupling, you could version control objects of the language and not text files. For example, a function could be versioned as a function, not a chunk of text. For example, I have seen cases with diffing where based on whatever algorithm, a very small logical change, (like moving a function up or down in the file along with a minor edit), creates a very confusing side by side diff based on whatever similar lines it think match up.
isoprophlex 5y ago
There's automated testing in a ci/cd pipeline to catch that, I suppose...
mananaysiempre 5y ago
It can, but like with other “rich” structures (type systems, data schemas, IDLs...) there is usually no single good solution, and when you need different ones to interoperate (either because you hit the limits of one of them or because you need to bridge two preexisting systems) you need to write a lot of tedious boilerplate at best and are completely stuck at worst. AFAICS that’s why amorphous sequences of bytes won as the fundamental (absence of an) abstraction in many places (files, networks, RAM, etc.). I would very much like for this not to be true, but there doesn’t seem to be a good solution. With syntax trees in particular, it’s also frequently difficult to find even a single good option for what you would reasonably want a diff to be: last I checked rich-text diffs usable over arbitrary HTML (even sans CSS) still sucked in half the cases you’d want. Line- and word-based diffs over the source also suck, naturally, but at least they do so uniformly. It’s not an accident Stack Overflow will usually try to show you a rich-text diff when editing but will occasionally fall back to word-diffing the Markdown. And a version control system needs to interoperate above all. Unlike, say, an IDE, and you do see attempts at semantic and even structured editing in IDEs. /me continues to fantasize about interbreeding Paredit and Pijul one day
smasher164 5y ago
Git allows you to use a custom diff tool for a specific file format. The problem is that these centralized source hosting/review tools only let you do about half of what Git can do.

k1ll3r 5y ago

you can write a diff tool that talks to an LSP server

nick__m 5y ago

This tight integration between language and general purpose tool is a nice idea with a terrible price. It would make tools a lot harder to develop and they would be a lot slower as they now have to perform significantly more work.

rfw300 5y ago

That strikes me as outside the scope of a feasible version control tool (and is probably undecidable in most cases). Seems like you’d be much better off handling that with a test suite and CI.

rileymat2 5y ago
I kind of agree, but if you have a very tight coupling, you could version control objects of the language and not text files. For example, a function could be versioned as a function, not a chunk of text. For example, I have seen cases with diffing where based on whatever algorithm, a very small logical change, (like moving a function up or down in the file along with a minor edit), creates a very confusing side by side diff based on whatever similar lines it think match up.

isoprophlex 5y ago

There's automated testing in a ci/cd pipeline to catch that, I suppose...

mananaysiempre 5y ago

It can, but like with other “rich” structures (type systems, data schemas, IDLs...) there is usually no single good solution, and when you need different ones to interoperate (either because you hit the limits of one of them or because you need to bridge two preexisting systems) you need to write a lot of tedious boilerplate at best and are completely stuck at worst. AFAICS that’s why amorphous sequences of bytes won as the fundamental (absence of an) abstraction in many places (files, networks, RAM, etc.). I would very much like for this not to be true, but there doesn’t seem to be a good solution. With syntax trees in particular, it’s also frequently difficult to find even a single good option for what you would reasonably want a diff to be: last I checked rich-text diffs usable over arbitrary HTML (even sans CSS) still sucked in half the cases you’d want. Line- and word-based diffs over the source also suck, naturally, but at least they do so uniformly. It’s not an accident Stack Overflow will usually try to show you a rich-text diff when editing but will occasionally fall back to word-diffing the Markdown. And a version control system needs to interoperate above all. Unlike, say, an IDE, and you do see attempts at semantic and even structured editing in IDEs. /me continues to fantasize about interbreeding Paredit and Pijul one day

smasher164 5y ago

Git allows you to use a custom diff tool for a specific file format. The problem is that these centralized source hosting/review tools only let you do about half of what Git can do.