Not all of us have that luxury. Not everyone is on Git, and some employers have in-house version control that sends email notifications at the time of the commit.
Yes, one can always schedule it with a script, but the advice still stands (I'm very much like the OP in that regard).
Not all programming work is done in hipster web companies following software development trends; there's a lot of employers out there who bought into proprietary VC systems a decade or more ago, and stick with them because of a combination of business needs, legacy requirements and the principle of "if it ain't broke, don't fix it".
At one of my previous jobs we had to deal with a proprietary, combined version control and time reporting system that to us, developers, felt like utter garbage. Only later on I learned that it was used by our main customer because it facilitated workflows useful in a mid-to-large corp, and some of our pain points were in fact conflicts between "the developer way" and "the business at large way".
The word is used to describe companies which tend to be overrepresented in tech communities compared to industry baseline, not tools.
As for "industry-standard tools", I find it hard to use this term in our industry. There's a diverse range of practices and recommendations.
Git is popular in some subset of the industry (around web in particular), but I'm hesitant in calling it an industry-standard tool. I don't know if there are estimates around the size of it, but there's plenty of proprietary 'shadow' tooling and practices hiding under the surface.
You can do the same thing with author information as well... had some fun with a Junior developer the other day who I was showing something to, and I just modified my commit as thought it was from him.
Git records the committer as well as the author, so even though a simple 'git log' shows only the author (which you can set with 'git commit --author', which is very useful when you want to apply an external patch from somebody), you can show both the committer and the author with e.g. git log --format <something>. As you probably know, but in any case, many companies, and a number of open source projects do require signed commits.
You can also set the date of the commit, so the person who wanted his commits to be at 09:00 - just do 'git commit --date="2019-05-22 09:00:00". Of course git logs both the commit date and the author date, internally.
> Git records the committer as well as the author, so even though a simple 'git log' shows only the author (which you can set with 'git commit --author', which is very useful when you want to apply an external patch from somebody), you can show both the committer and the author with e.g. git log --format <something>.
It’s all just data. Even if git didn’t offer the ability to edit all of these
Anyway, even if git itself did not provide the tools to set this information on a per-commit basis you could still of course change your ~/.gitconfig and adjust your system clock time prior to committing. Or you could edit the commit data using a third-party tool that you yourself or someone else created. Like I said, it’s all just data.
Just because a file says something doesn’t mean that what it is saying is true, basically. Same goes for a piece of software.
And signing provides limited value as well, though useful to some. But for example you still wouldn’t know that the date information was correct even if the commit was signed.
Personally though I prefer to just commit things when I do them and push them immediately. And I don’t sign my commits but I would be willing to do so if there was any reason to — for example if it was the policy of a company I worked for that we do so.
Suppose someone checks some malicious code into the repo. Without signed commits it can be very difficult to determine or prove who was responsible. That ability to audit is important to most companies, and should be important to most popular open source projects as well.
The idea that most corporate dev teams, as they exist in the real world, are sophisticated enough to glean managerial and employee performance information from their code repositories is laughable.
