4 ms·

BIG PROBLEM with git is that it works in terms of editor lines and not in language constructs. It should instead track changes in terms of language constructs.

BIG PROBLEM with git is that it works in terms of editor lines and not in language constructs. It should instead track changes in terms of language constructs. For example, tracking the history of a class individually, an interface, etc... changes could be logged automatically. For this to work it would, of course, require to be adapted for each language. Furthermore, it could work in architecture terms, such as an MVC files that could be tracked as an individual unit. The architecture for a file system could be defined and enforced in a git file, it could spot missing pieces. Also, it needs dependency management for these units.

G3rn0ti 3y ago
> It should instead track changes in terms of language constructs. This does not generalize very well. On top of GIT‘s core data structures and file management facilities you would also need parser plugins for all languages now and additional commands to manage language constructs. This would make it even more difficult to grasp. I would say version control of text files in general is not an easy problem. GIT‘s complexity arises from the complexity of the problem it solves. Perhaps the user interfaces of subversion or mercurial are easier but I don’t think they lift the burden of understanding version control and why it is necessary from beginners …
lolinder 3y ago
I can see two ways to implement something like this: 1. Completely alter the paradigm for editing software: from editing text to editing the AST (or a projection of it). See Unison [0]. This gives you fine-grained understanding of every aspect of the development flow, but requires rewriting most of the tooling that developers are already using. 2. Layer the smart features on top of the existing text streams. This gives you less control and is more resource intensive, but you don't throw away the entire developer ecosystem. If we choose #1, we waste millions of man-hours building these tools for every new language. If we choose to layer our language-specific features on top of text, then why does this need to happen at the Git level instead of at a higher level of abstraction? IntelliJ, for example, can already use the git history to tell you who wrote a given method and when. This kind of functionality could, in principle, be extended to following the history of a method when it's moved or renamed. Is there any benefit gained by having the VCS itself do the language-aware processing instead of having language-aware tooling layered on top of the VCS? [0] https://www.unison-lang.org/ https://www.unison-lang.org/
Espressosaurus 3y ago
That is A problem, but the biggest problem IMO is that it doesn't make it easy to perform the tree operations. Everything has a special syntax, the reflog isn't ergonomic to use if you screw up, the staging area is a bit of unnecessary cruft for most workflows, and the branches-as-pointers model doesn't match how most businesses use a VCS. Once you understand a DAG and the concept of a hunk, it's easy to say what I want to do, but using the command line tool makes it a pain in the ass. It also doesn't help that the rest of the user interface is a bunch of complicated behaviors tacked onto marginally related commands. The underlying model is also weird. You would expect it to be diffs, but instead it's full files. Fortunately you can ignore that. Git: unnecessarily difficult since it was invented.
CapsAdmin 3y ago
It could be something that just sits outside of git and uses the raw git history to figure out what changed in a semantic way. It doesn't have to be part of git. This sounds like something C# programmers would dream of having or making.
erik_seaberg 3y ago
We should be creating more domain-specific languages, but this would be an impediment.
namtab00 3y ago
this existed, at least for diffs of C#, as semanticmerge (bundled with GMaster and PlasticSCM), from Codice Software, a Spanish company. since it got bought by Unity, they've discontinued it... so my license of it evaporated. I've missed it a lot, having to diff with kdiff3

G3rn0ti 3y ago

> It should instead track changes in terms of language constructs. This does not generalize very well. On top of GIT‘s core data structures and file management facilities you would also need parser plugins for all languages now and additional commands to manage language constructs. This would make it even more difficult to grasp. I would say version control of text files in general is not an easy problem. GIT‘s complexity arises from the complexity of the problem it solves. Perhaps the user interfaces of subversion or mercurial are easier but I don’t think they lift the burden of understanding version control and why it is necessary from beginners …

lolinder 3y ago

I can see two ways to implement something like this: 1. Completely alter the paradigm for editing software: from editing text to editing the AST (or a projection of it). See Unison [0]. This gives you fine-grained understanding of every aspect of the development flow, but requires rewriting most of the tooling that developers are already using. 2. Layer the smart features on top of the existing text streams. This gives you less control and is more resource intensive, but you don't throw away the entire developer ecosystem. If we choose #1, we waste millions of man-hours building these tools for every new language. If we choose to layer our language-specific features on top of text, then why does this need to happen at the Git level instead of at a higher level of abstraction? IntelliJ, for example, can already use the git history to tell you who wrote a given method and when. This kind of functionality could, in principle, be extended to following the history of a method when it's moved or renamed. Is there any benefit gained by having the VCS itself do the language-aware processing instead of having language-aware tooling layered on top of the VCS? [0] https://www.unison-lang.org/ https://www.unison-lang.org/

Espressosaurus 3y ago

That is A problem, but the biggest problem IMO is that it doesn't make it easy to perform the tree operations. Everything has a special syntax, the reflog isn't ergonomic to use if you screw up, the staging area is a bit of unnecessary cruft for most workflows, and the branches-as-pointers model doesn't match how most businesses use a VCS. Once you understand a DAG and the concept of a hunk, it's easy to say what I want to do, but using the command line tool makes it a pain in the ass. It also doesn't help that the rest of the user interface is a bunch of complicated behaviors tacked onto marginally related commands. The underlying model is also weird. You would expect it to be diffs, but instead it's full files. Fortunately you can ignore that. Git: unnecessarily difficult since it was invented.

CapsAdmin 3y ago

It could be something that just sits outside of git and uses the raw git history to figure out what changed in a semantic way. It doesn't have to be part of git. This sounds like something C# programmers would dream of having or making.

erik_seaberg 3y ago

We should be creating more domain-specific languages, but this would be an impediment.

namtab00 3y ago

this existed, at least for diffs of C#, as semanticmerge (bundled with GMaster and PlasticSCM), from Codice Software, a Spanish company. since it got bought by Unity, they've discontinued it... so my license of it evaporated. I've missed it a lot, having to diff with kdiff3