4 ms·
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,
by city41 8y ago
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.
- peterwwillis 8y agoThis 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.
- city41 8y agoThat's a fair point. Thinking more on it, you're right it is more about making reviewing old commits easier.
- wst_ 8y agoIf 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.
- int_19h 8y agoDecoupling 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.
- Negitivefrags 8y agoWhen 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 agoWouldn'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 agoThen 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 agoI'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 agoThe 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.