isn't pretty, but it is meaningful and will tell you a great deal about a project and its developers... I trust that.
Here is a (made up), but generally realistic git log
git log | grep -i WIP
mon 5pm - WIP, going to work on this from home
tue 4:45pm - WIP, going to work on this from home
wed 2:30pm - WIP, meeting
wed 5pm - WIP
thu Noon - WIP, working from the cafe on my laptop
fri 5pm - WIP, working from home
sat 3pm - WIP, heading home sick for the day
Does it really matter to anyone, and count as anything but noise to know that I committed my work in to the repository just so that I could work on it from a different computer. I can't imagine how low the signal to noise ratio would be if every person on the team did this.
It does tell me a great deal about your development habits, yes.
Maybe not information that I care to do much more than skim, of course, unless I'm your manager looking for reasons why you might be working from home too much. :) (That said, there's probably some cool deep learning applications here...)
Some of the information, for instance, is that maybe you are working on pieces too large at a time and should find more ways to break them into smaller units of work that you can more easily commit in logical piece at a time rather than "snapshot dumps" between computers.
Like I said, from a hyberbolic standpoint, how the sausage is made isn't pretty and is full of garbage sometimes, but it is informative.
I'm a manager, and I'd be happy to see commit messages about working from home. My team would never write commit messages like this, they are of negative value to the team. I would ask them to squash. If I saw these commit messages pushed, the employee would get a warning.
I can relate to that. I don't like those WIP commits on a feature branch (when the program is crippled or even doesn't compile or doesn't pass the tests, when the code is filled with temporary "printf" debug messages, etc.) to be in the history of the master branch.
Ideally, every commit that I'm making should be preferably not big, but logically complete and working. The problem is that sometimes I want to work on another branch and I have to commit in the middle of the work so I can checkout into the other branch in which case (without a squashing merge) the "offending" WIP commit would end up in the master branch's history.
I can't trust git stash anymore. I mistyped something and it blew away a lot lot lot of work. So now I just commit stuff. If I want to get rid of the commit, I can follow it up with a reset.
Not true. From the git stash man page: "If you mistakenly drop or clear stashes, they cannot be recovered through the normal safety mechanisms."
Git stash is more dangerous than other git commands, and I've personally witnessed more people losing work with stash accidents than with commit accidents. There may be plumbing commands that can get you there like fsck but the fact of the matter is you are better off committing or branching, from a safety standpoint.
That said, I've been happy to debate the larger implications that there are UI/UX tweaks/story-telling that could make even the work-in-progress non yet published stuff more appealing to publish without needed to mutate it from its as-developed states... But yes, I was mostly speaking to published commits.
I think I would go insane with commit messages like that. Sorry, but they have very little value - I'm afraid that it's not important to know that you've gone out for a meeting, a coffee or sick. Commit messages in a mainline tree should be reserved to explain what you've done, and nothing more.
I would hate to have done a bisect to land on your commit "WIP, heading home sick for the day" as the one that caused the bug. By all means, create a WIP branch and if you can then push this WIP branch to the main repo, but please use commit squashing into logical units of change when merging into the feature branch or main trunk!
Git was designed for those type of low-friction wip commits in private/local/unpublished branches. Many programmers have a concept of "savepoints". Think of "git commit" as an "implementation detail" of that savepoint. Those savepoints were intended to extend the programmer's mental scratch space and never meant for public consumption. Therefore, squash/rebase is a logical followup step to consolidate meaningless savepoints into a meaningful commit.
A private "commit" in git does not have the same semantics as the lock & checkout type of commits in svn/Perforce. Programmers should not be discouraged from making cheap commits as often as they want even with nondescriptive titles because those commits weren't meant for public dissemination anyway. Being judgmental about those wip commits makes no sense.
