Hacker News Reader

Comment by city41 | Hacker News Reader

I think the most important thing is to create atomic commits. Each commit should do one thing and do it cleanly. In other words, if you later regret the change, you should only have to revert one commit to remove it. If when reverting you need to go back and reapply part of the commit (due to it being unrelated), that's the sign of a bad commit.

I've worked with people who were adamant white space and formatting changes should always be in their own commit. But in my experience, it's never been a problem.

View on HN

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.

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.

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.

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

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

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.

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.

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.

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?

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

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.

This is subjective. Sometimes your change has to touch other things in small ways, that other code then depends on over time. Even if your project tries to avoid this, it'll happen to any big or old enough code base.

I think your suggestion is most useful for making code review easier. It's annoying to read 5 commits to understand a change versus just one.

If your change must touch too many other things that may be a sign of tight coupling. Not a good sign. Maybe it would be good to think about splitting things apart as a separate lib, or service. Then you'd be able to make small, safe, changes that are atomic.

Decoupling is not free (especially long term, because it creates a new boundary), and when you decouple without any particular reason to do so, you often end up with more complicated code to do the same thing.

That's a fair point. Thinking more on it, you're right it is more about making reviewing old commits easier.

Reply on news.ycombinator.com