3 ms·

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

by pilif 17y ago

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

timf 17y ago
"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-bisect.html http://www.kernel.org/pub/software/scm/git-core/docs/git-bis...
- pilif 17y ago
  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)
sorbits 17y ago
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 ;)
- dasil003 17y ago
  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.
- pilif 17y ago
  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.
  - sorbits 17y ago
    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.
    - bdr 17y ago
      I think people interpreted your comment as saying "You won't look at most commits ever again, so don't be so anal."
- apag 17y ago
  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.
apag 17y ago
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.)

by pilif 17y ago

timf 17y ago

"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-bisect.html http://www.kernel.org/pub/software/scm/git-core/docs/git-bis...

pilif 17y ago
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)

sorbits 17y ago

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 ;)

dasil003 17y ago
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.
pilif 17y ago
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.
- sorbits 17y ago
  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.
  - bdr 17y ago
    I think people interpreted your comment as saying "You won't look at most commits ever again, so don't be so anal."
apag 17y ago
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.

apag 17y ago

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