3 ms·

Wouldn't it be nice if git had an understanding of what was being committed, and could identify white-space/formatting changes versuses substantive changes? I s

Wouldn't it be nice if git had an understanding of what was being committed, and could identify white-space/formatting changes versuses substantive changes? I suspect it could automatically fix these types of common issues.

jnurmine 8y ago
Then Git would have to be content-aware, as sometimes whitespace is meaningful and sometimes just formatting. Add different ways to format code in, say, C, C++, Java, and so on, and you'd add a whole lot of unnecessary complexity into a version control software...
- Gibbon1 8y ago
  I've dealt with tracking schematic capture and layout software. And just a infinitesimal amount of database stuff. The difference I note is that software version control systems are hopelessly broken because they work on text and not structured data. With a schematic you can reorganize a schematic and then compare the netlist and parts and if they are different you broke something. You can generate meaningful descriptions of of changes. Changed all the parts of this type to that type. Renamed these parts to these new names. Problem is no one designs languages to be able to do that.
  - marcinzm 8y ago
    The problem is that to properly understand the structure of the code you need to load in all dependencies of the code (both in other files and imported third party modules). That's time consuming and has to be done somewhere. As a note, in Scala, scalameta will do just that and then dump out a structured view (in a specified protobuf format) of your code which you can work with.
    - Gibbon1 8y ago
      That why I said a problem is languages aren't designed with that in mind. I think C# is pretty close since it was written with debugging as first class feature. But to really get the benefit you need a language that's tightly coupled to refactoring tools. And that means giving up on Unicode text as the file format. There are other problems, anything more than naively comparing and diffing AST's is a hard problem. I've also seen some really bad things with editing non text data. Like the file you've been editing for a few days is corrupted.
      - int_19h 8y ago
        There's nothing wrong with Unicode text as a serialization format, so long as all your diff tools operate on the deserialized graph. I mean, when you do a diff on a database, do you care about the binary format of its files on disk? And I don't see why you can't do this sort of thing with most languages that we already had. Indeed, this immediately reminded me of structured code search in IntelliJ IDEA, which has been around since early 00s. What's special about C# in that regard?
        Gibbon1 8y ago
        > What's special about C# in that regard? Not unique but far as I understand you can parse a C# module without knowing anything about it's dependencies. > There's nothing wrong with Unicode text as a serialization format, so long as all your diff tools operate on the deserialized graph. The point is you need to actually edit the de-serialized graph not the Unicode expression of program. Changes to the code aren't expressed as changed to the text, they're expressed as changes to the graph. AKA diff is object foo nenamed object baz. And that's it.
        int_19h 8y ago
        Most languages can be parsed without knowing dependencies of a translation unit. I would say that something like C and C++ (where you need to know if something is a type or not in many contexts) is an exception to that rule. And you don't have to edit the graph. You can still edit the serialized representation directly. So long as you diff the graph, how the changes were made doesn't matter. For example, there already are XML and JSON diff tools that do advanced structural diffing, and they don't care how that XML or JSON was edited.
- speedplane 8y ago
  > Then Git would have to be content-aware, as sometimes whitespace is meaningful and sometimes just formatting. Yes, being content aware is the key. No question, it isn't easy. I'm not sure it's possible, but one could imagine that another tool wraps itself around git, and has a better understanding of the full the underlying project, the languages used, and their dependencies. Git can still be used for the lower level commits, but the higher level wrapper could do much more.

jnurmine 8y ago

Then Git would have to be content-aware, as sometimes whitespace is meaningful and sometimes just formatting. Add different ways to format code in, say, C, C++, Java, and so on, and you'd add a whole lot of unnecessary complexity into a version control software...

Gibbon1 8y ago
I've dealt with tracking schematic capture and layout software. And just a infinitesimal amount of database stuff. The difference I note is that software version control systems are hopelessly broken because they work on text and not structured data. With a schematic you can reorganize a schematic and then compare the netlist and parts and if they are different you broke something. You can generate meaningful descriptions of of changes. Changed all the parts of this type to that type. Renamed these parts to these new names. Problem is no one designs languages to be able to do that.
- marcinzm 8y ago
  The problem is that to properly understand the structure of the code you need to load in all dependencies of the code (both in other files and imported third party modules). That's time consuming and has to be done somewhere. As a note, in Scala, scalameta will do just that and then dump out a structured view (in a specified protobuf format) of your code which you can work with.
  - Gibbon1 8y ago
    That why I said a problem is languages aren't designed with that in mind. I think C# is pretty close since it was written with debugging as first class feature. But to really get the benefit you need a language that's tightly coupled to refactoring tools. And that means giving up on Unicode text as the file format. There are other problems, anything more than naively comparing and diffing AST's is a hard problem. I've also seen some really bad things with editing non text data. Like the file you've been editing for a few days is corrupted.
    - int_19h 8y ago
      There's nothing wrong with Unicode text as a serialization format, so long as all your diff tools operate on the deserialized graph. I mean, when you do a diff on a database, do you care about the binary format of its files on disk? And I don't see why you can't do this sort of thing with most languages that we already had. Indeed, this immediately reminded me of structured code search in IntelliJ IDEA, which has been around since early 00s. What's special about C# in that regard?
      - Gibbon1 8y ago
        > What's special about C# in that regard? Not unique but far as I understand you can parse a C# module without knowing anything about it's dependencies. > There's nothing wrong with Unicode text as a serialization format, so long as all your diff tools operate on the deserialized graph. The point is you need to actually edit the de-serialized graph not the Unicode expression of program. Changes to the code aren't expressed as changed to the text, they're expressed as changes to the graph. AKA diff is object foo nenamed object baz. And that's it.
        int_19h 8y ago
        Most languages can be parsed without knowing dependencies of a translation unit. I would say that something like C and C++ (where you need to know if something is a type or not in many contexts) is an exception to that rule. And you don't have to edit the graph. You can still edit the serialized representation directly. So long as you diff the graph, how the changes were made doesn't matter. For example, there already are XML and JSON diff tools that do advanced structural diffing, and they don't care how that XML or JSON was edited.
speedplane 8y ago
> Then Git would have to be content-aware, as sometimes whitespace is meaningful and sometimes just formatting. Yes, being content aware is the key. No question, it isn't easy. I'm not sure it's possible, but one could imagine that another tool wraps itself around git, and has a better understanding of the full the underlying project, the languages used, and their dependencies. Git can still be used for the lower level commits, but the higher level wrapper could do much more.