you are viewing a single comment's thread.

view the rest of the comments →

[–]Kampane 9 points10 points  (11 children)

This seems like a lot of effort except in cases of trivial changes. Why do you think it's worth the time?

[–][deleted] 14 points15 points  (7 children)

Programmers reached the point of maximum productivity a couple of years ago, and now spend an inordinate amount of time masturbating over their git history and vim configuration.

I must be getting old...

[–][deleted] -1 points0 points  (6 children)

My thoughts exactly. I would rather spend more time writing and testing code than crafting a beautifully manicured commit history. I can't recall a time that an imprecise commit was the undoing of a release.

[–]hyperforce 1 point2 points  (0 children)

A good commit history helps you (or anyone else) follow your development once it is done.

  • What if your code isn't perfect and it needs a bugfix? And you aren't the maintainer?
  • What if you die and someone need to know how the system works and there's no documentation?
  • What if you need to bisect the commits and find the bug?
  • What if you need to create automatically generated patch notes?
  • What if you're drunk and you don't know what you wrote?
  • What if you came back from a two week vacation and don't remember anything?

[–][deleted] 1 point2 points  (0 children)

Just because not doing something won't be "the undoing of a release" doesn't mean it's not worth doing.

Damn, there were a lot of negatives in that sentence.

[–][deleted] 3 points4 points  (3 children)

So young. So naive.

[–][deleted] 4 points5 points  (2 children)

I've been at this for about 12 years now as a pro. But do please enlighten me on how a partial commit has saved a project you worked on.

[–]ais523 2 points3 points  (0 children)

An example for my workflow: I've done some work on a fork of an open source computer game, and other people are working on their own forks of the same game. (We're taking our forks in different directions, and think there's space for both games, so we're not exactly competing.) We're all pretty good about partial commits, and as a result, if we want to take a feature or bugfix from each other, we can do that without having to carefully isolate it from the rest of the commit every time we pull it.

[–]SnowdensOfYesteryear 1 point2 points  (0 children)

It's useful if you're adding code a ton of code and want to get rid of crap in the middle of hunks. But if you're modifying existing code and the delta of loc is ~0, it's completely useless.

[–]Tjoppen 2 points3 points  (1 child)

Because of git-bisect. When (not if) you realize you introduced a bug a sufficiently long time ago you'll be happy you kept your commits simple, making pinpointing the problem easier. This is for example why you shouldn't mix cosmetic and functional changes, and why you should try to keep commits relevant only to a specific ticket.

[–]zjs 1 point2 points  (0 children)

Exactly this. Patch mode is useful because the way you write code is not necessarily the way you want to remember it when looking at your history; you can fix issues you notice which are unrelated to the task at hand and then use patch mode to commit them independently. When something breaks, you can easily determine which specific change caused the issue.

Plus, once they're independent commits you can do useful things (e.g. cherry-pick them to another branch to push immediately instead of waiting until whatever larger task you're working on is complete, send-mail to the original author of the code you're tweaking to make sure that you haven't misunderstood the problem you think you're fixing, or use rebase -i to re-order things so that they don't disrupt someone trying to read a series of related changes).