
Utter Disregard for Git Commit History - kiyanwang
https://zachholman.com/posts/git-commit-history/
======
anotheryou
Personally I like to push as soon as it's not broken to have something to
revert too. This also means e.g. function and design might be in different
commits. Bundeling more together makes the commits easier to read, but leaves
me without version history in between steps. Is there a trick to have both?

------
dwringer
I shudder to think what kind of names he probably uses for local variables.

------
xkxx
If your commit messages are meaningless, why not make them empty? Like this:
`git commit -m "" \--allow-empty-message`.

~~~
BugsJustFindMe
It's like you didn't actually read the same article that I did. Nowhere does
the author say that commit messages are meaningless. "foo", followed by
"revert foo" carries a LOT of meaning. It means you tried something and it
didn't work. If you leave that out of your history you risk not remembering
that you tried something and that it didn't work. You don't have to look at
the revert commit. For all other purposes, the two commits may as well not
exist, but together they carry extremely useful meta information.

Disregarding the low level commit messages and using commit clusters for
features allows you to _easily_ track when and how this happens. Using single
atomic feature commits does not.

~~~
xkxx
How is "Revert foo" different from "Revert
52e8ace0571ec9ac9b669bc5acfd0bcea537805d"?

> Nowhere does the author say that commit messages are meaningless

He doesn't. I say it. His commit messages are meaningless. To understand
what's going on, you need to read his diffs, not commit messages. In his
workflow, only reverts and merges provide any context, and for them git
creates meaningful commit messages automatically.

~~~
BugsJustFindMe
It's different from rebasing to squash many commits into one. The article has
nothing to do with hashes. Foo is also easier to parse mentally than umpty
digits of hexadecimal vomit.

~~~
xkxx
> It's different from rebasing to squash many commits into one.

What is different?

My point is, if you don't write meaningful commit messages for some commits,
you probably don't need any commit messages for those commits at all. It
reduces noise for people who read your `git log`. If you make a commit and
then immediately revert it, instead of "foo", it's better to write at least
"tried ...; didn't work".

~~~
BugsJustFindMe
The posted article is about whether to squash commits or not. The posted
article is comparing the view of the commit as ultimate arbiter of feature
history or the commit cluster (aka Pull Request) as ultimate arbiter of
feature history. Putting details below the fold on a single feature commit
makes them 99% invisible.

The best solution, which the posted article suggests, is for git to natively
support commit clusters. So that you can have just feature information and
also meta information that isn't 99% invisible.

------
Pica_soO
TL,DR: Pedantic People ranting about missing commit history. Slackers
declaring it a art and "look into the diff". Not present- pragmatics training
NN on the diffs, so that changelog messages get autogenerated.

~~~
BugsJustFindMe
This might be the least apt TLDR I've ever read. How did you come up with it?

