5 ms·

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

by xkxx 10y ago

BugsJustFindMe 10y ago
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 10y ago
  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 10y ago
    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 10y ago
      > 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 10y ago
        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.
    - deleted 10y ago
      [deleted]
    - deleted 10y ago
      [deleted]

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

by xkxx 10y ago

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

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 10y ago
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 10y ago
  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 10y ago
    > 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 10y ago
      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.
  - deleted 10y ago
    [deleted]
  - deleted 10y ago
    [deleted]