I strongly agree.

Git isn't only code sharing that you commit and forget. It is a database of code that tracks what changed, why changed, who changed and when changed.

Want to know why a piece of code exists? Find the commit that introduced it, read the message. If it's not enough, you can search the commit and find the discussion on GitHub/GitLab/etc.

A new bug suddenly appeared? Use git bisect to find what was the commit that introduced it.

Some months ago I posted some tips about using Git as a debugging tool, if you want to read more about it: https://news.ycombinator.com/item?id=39877637

See also:

    git log -L:funcname:file

funcname will be matched after wrapping it in a "function declaration identifying" regexp.

Get the entire history of a given function (as long as it was in <file>). Not a daily driver, but sometimes unimaginably valuable.

Could you please give a concrete example of how to use funcname? I tried looking in the man page and didn't get it.

I work in C++, so I might be looking for the history of

        Session::set_state (XMLNode const & node)

I would write:

        git log -L:set_state:session_state.cc

If I worked in C, and I had this in a file:

        void
        some_function_name (type1_t t1, type2_t t2)

I would write

        git log -L:some_function_name:thefile.cc

Thanks!

I'll check it and I'll update my article with that!

I'm using git history may be one time a year. And even those times might be just of pure curiosity: who's that dumb who did that bug. Basically it's useless for me. So I don't care much about commits. Git for me is a collaboration tool and code backup tool, and that's about it. Nobody will look at my 1-year old commit and I'm not going to look at anyone's 1-year old commit.

> who's that dumb who did that bug

You can find more than that, e.g. what was the context of the introduction of a code, find the discussion about that introduction, what was the situation of the project when the code was introduced, etc. But even if you only want to blame, it is enough to keep a good commit history.

> Nobody will look at my 1-year old commit and I'm not going to look at anyone's 1-year old commit.

If you commit history isn't good no one will. And no one will benefit of using git. And then you don't need to use git.

> Git for me is a collaboration tool and code backup tool, and that's about it.

If you don't see the point of having a commit history, there are other tools that fit it better. For code collaboration, JetBrains' Code With Me and VSCode's CodeTogether. For code backup, Google Drive or Dropbox.

Well, it completely depends on your job and work style. Personally I'm a site reliability engineer, so when something breaks it's an invaluable step to look at the commit history to see what changed, when, how, why, and by whom.

I'm searching through commit histories several times per hour.

Good commit messages can be used in lieu of official documentation, and that makes them veey helpful.

Whether or not relying on git commit messages for source of truth documentation is a good idea is debatable, but personally, when people do it I'm glad they did.