This article gives a perfect example of why you would want to take advantage of the git index: the author was talking about different versions of coffee sometimes producing different output which lead to commits going back and forth between the two versions.
The author is right: this is annoying.
Now, the correct way to solve this would probably be to either not check in generated files, to leave the JS out of the repo, or, if that's not possible due to politics, then use the same version of coffee which I would highly recommend anyways because it gets rid of really bad WTFy issues if one version of the compiler has a bug which manifests itself in an application bug which will then only be seen if the last commit was done by the person with the broken compiler.
Anyways. Let's say you can't use the same compiler and you have to check in JS in addition to coffee (you are not trying to sneak in coffee by ONLY committing the JS, are you?)
Now we have the perfect oportunity to show off the git index:
Instead of committing the whole file, you would use add -p to only select the changes which are actual code changes and not changes in compiler output.
Then you would only commit those changes and then undo the unneeded stuff and test again, to ensure that you added the right lines to the index (commit --amend or rebase -i if not).
This will give you a much cleaner history, which will be a huge help when blaming or reviewing the code. No more annoying flip-flopping between compiler output styles. No more meaningless changes in a commit. All the changed lines in the diff are the lines that count. The lines you should look at when reviewing. No risk of missing the trees in the forest.
But, you might say, history rewriting is bad. I don't want to commit something I haven't tested.
Remember though: you haven't pushed yet. You haven't altered public history yet. Nobody knows about those commits yet. You have all the time for testing, patching and massaging commits. Only once you pushed, your changes (should) become set in stone. Only then, history gets written. Only then it can't be changed any more.
This is why I love rebase and I'm really glad I finally found a good real-world example to show why.
Let me readily acknowledge that our process wasn't optimal. The CoffeeScript version-change happened while I was completely offline for a week, having dumped the next dev right in the middle of things with insufficient handover, so we caught that a bit late.
In hindsight (1) I should have used something other than Make for my build process and (2) I should have figured out a way to move some of the build upstream.
The author is right: this is annoying.
Now, the correct way to solve this would probably be to either not check in generated files, to leave the JS out of the repo, or, if that's not possible due to politics, then use the same version of coffee which I would highly recommend anyways because it gets rid of really bad WTFy issues if one version of the compiler has a bug which manifests itself in an application bug which will then only be seen if the last commit was done by the person with the broken compiler.
Anyways. Let's say you can't use the same compiler and you have to check in JS in addition to coffee (you are not trying to sneak in coffee by ONLY committing the JS, are you?)
Now we have the perfect oportunity to show off the git index:
Instead of committing the whole file, you would use add -p to only select the changes which are actual code changes and not changes in compiler output.
Then you would only commit those changes and then undo the unneeded stuff and test again, to ensure that you added the right lines to the index (commit --amend or rebase -i if not).
This will give you a much cleaner history, which will be a huge help when blaming or reviewing the code. No more annoying flip-flopping between compiler output styles. No more meaningless changes in a commit. All the changed lines in the diff are the lines that count. The lines you should look at when reviewing. No risk of missing the trees in the forest.
But, you might say, history rewriting is bad. I don't want to commit something I haven't tested.
Remember though: you haven't pushed yet. You haven't altered public history yet. Nobody knows about those commits yet. You have all the time for testing, patching and massaging commits. Only once you pushed, your changes (should) become set in stone. Only then, history gets written. Only then it can't be changed any more.
This is why I love rebase and I'm really glad I finally found a good real-world example to show why.