git commit frequency

Solution 1:

The guideline for the Git project itself (and the Linux project, AFAIK) is one commit per "logically separate changeset".

This is a little ambiguous, but you probably don't want to commit every few days if you're working on a project constantly, and you probably don't want to commit after every function change - if you've edited several functions in several different files, you want to commit all of the related functionality together if you can and provide a useful commit message with it. All of the code modified in each commit should be related, but it can (and probably should) certainly be across several files.

What you probably want to keep in mind is in code reviews. If someone is trying to decide if they should merge your work in, it's much easier for them to process the work being introduced if you have each commit logically contained and separate from each other. That lets you (or others) cherry pick work effectively - if you have three commits with one function modified in each but they're all coupled somehow - you can't apply one without the other two without breaking the codebase - then they should probably be squashed down to one commit.

Solution 2:

I also track some other projects using git like emacs,wordpress etc. I see that they do not commit that often.

One of the nice things about git is that you can commit as often as you like, and then when you want to do an upstream commit you can squash several related commits together into one nice clean commit using git-rebase.