4 ms·

When you are trying to merge a commit to a branch, and it wont merge cleanly because of some trivial white space change someone made in an unrelated commit, you

When you are trying to merge a commit to a branch, and it wont merge cleanly because of some trivial white space change someone made in an unrelated commit, you will understand why people dislike it. It's a pain in the ass. At least if the whitespace / formatting changes are in their own commit, then you can just merge that one first and continue on with your day, rather than having to manually resolve the merge problem potentially leading to more merging problems down the road.

speedplane 8y ago
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.
  - 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.
int_19h 8y ago
The other reason is that it all shows up in history of the affected lines of code. Much later, when I'm looking at a line, and I see git blame saying "Fixed ...", I have to go look at the commit to figure out why it touched that line - and having to spend that time only to find out that the only effect on that one line was replacing two spaces with one is wasteful. When it's a separate commit with a clear message that says it's formatting-only, you can just skip it.

speedplane 8y ago

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

int_19h 8y ago

The other reason is that it all shows up in history of the affected lines of code. Much later, when I'm looking at a line, and I see git blame saying "Fixed ...", I have to go look at the commit to figure out why it touched that line - and having to spend that time only to find out that the only effect on that one line was replacing two spaces with one is wasteful. When it's a separate commit with a clear message that says it's formatting-only, you can just skip it.