Comment by pilif | Hacker News Reader

Comment by pilif | Hacker News Reader

using the git index (and of course "add -p" and "rebase -i" which are closely related), I managed to increase the quality of my commits by a huge margin.

What is the value of that extra-work to make commits "nice"?

It makes everything related to the history fun: merges, blames, sending around and applying patches or even just browsing the history.

But it's not just the aspect of fun: Having a clean history where each commit does one thing and only one thing saves you huge amounts of work when you are trying to find a bug in the code or when you are trying to understand a change another person made.

I can't provide numbers but it's my gut-feeling that 5 minutes of additional work while commiting can easily amount to 30 minutes of effort saved later on - at least for the person having to sort through the history doing merges or changelog updates - which in this case happens to be me.

Of couse I got really quick at commiting even huge amounts of work in the form of really small localized patches - it took me months though to get quick and error-free), so what takes me 5 minutes might take a beginner to the concept of the git index 30 minutes or more - but this is just the same with all new concepts of development that you are learning.

I would never want to go back to the ugly world that is the mashing-stuff-together that is subversion for example. I even get an uneasy feeling the rare times I do a "git commit -a".

"Having a clean history where each commit does one thing and only one thing saves you huge amounts of work when you are trying to find a bug in the code"

Especially when employing 'git bisect': http://www.kernel.org/pub/software/scm/git-core/docs/git-bis...

right. I wanted to add that after writing my comment and before posting it, but I got distracted and then forgot.

Thanks for the pointer.

(small anecdote about git bisect: I was talking about "git bisect" at work and a comment of a coworker clearly not interested in the marvel that is git bisect said: "bisect my ass". I probably don't have to explain you how often we are now using that phrase in various non-git related contexts)

Good comment. I just want to react to the last sentence.

I use `git commit -a` plenty and without compunction. There are many times where a tweak or very simple feature doesn’t involve any exploration, and in those cases I rarely need the elaborate staging dance to make a sensible commit. I review the patch and find there is no need to break it down… why go through the index in that case?

The index is just a tool, and so is `-a`. Judge their use, not the tools themselves.

(Of course, sometimes I realise belatedly that a simple feature commit is not as straightforward as it seemed. Well, it would be belated if we weren’t talking about git. Rebasing (interactively, in particular) saves the day in that case. Once again: git goes out of its way to get out of mine. This is really the central point.)

my gut-feeling that 5 minutes of additional work while committing can easily amount to 30 minutes of effort saved later

I don’t need to rationalize being anal about my commits, of most I never visit again ;)

However when one causes a bug that you discover a few months later, being able to isolate the commit quickly could save you hours or days.

YOU might not. But you might actually be nice to your coworkers (or open source project members) that do.

It's just a matter of basic politeness to others.

And in fact, I would reject a patch to any of my code out there that doesn't clearly separate different things into different patches.

Too many times in my SVN days I witnessed strange bugs appearing in some commits that otherwise only contained whitespace changes labelled with the all-famous commit message "fixes".

Never again.

Not sure why I was downvoted and get these replies.

I wasn’t being sarcastic, I do spend lots of time making my commits (and everything else for that matter) ready for inspection by her royal queen — I know others with this same behavior, and my comment was merely meant to say “don’t rationalize it” — I do it to feel good, well, to not feel bad (about “leaving a mess”) is probably closer to the truth.

I think people interpreted your comment as saying "You won't look at most commits ever again, so don't be so anal."

That’s true, most of the time it doesn’t really matter.

But it’s like properly formatting and indenting your source. Any one particular instance of sloppiness is irrelevant, but in the aggregate, the care you put into it really makes a difference in the feel of your works.

Reply on news.ycombinator.com