3 ms·

Some information is worth loosing. Personally, I get exactly zero value from "Fixed a typo", "Fixed that errant semicolon", "fixed tests broken 3 commits ago"

Some information is worth loosing. Personally, I get exactly zero value from "Fixed a typo", "Fixed that errant semicolon", "fixed tests broken 3 commits ago" commit messages that come hand in hand with a hard and fast "never rewrite history" policy. If that information is valuable to you, great! This is why we have several ways to do things. The trend you're seeing simply seems to indicate (mildly indicate, at best) that a larger percentage of HN readers prefer to squash and merge. Each to their own.

npsimons 10y ago
Very much this. I keep saying: I. Don't. Care. About. Every. Little. Sneeze. A. Developer. Had. On. The. Way. To. Closing. A. Ticket. See how annoying that is? That's what it feels like to me to read non-squashed commits.
- aeontech 10y ago
  Why does everyone seem to insist that there's only two options? option A) SQUASH ALL THE THINGS option B) HISTORY IS SACRED AND HOLY We just make sure that the developer rebases and squashes the meandering micro-commits into parent logical units before merging. This gives us both sensible logical commits, and avoids monster commits. I spend enough time spelunking through history that I dread seeing something like this when I need to track down the context for a particular change client/something.js | 114 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ critical/something.rb | 41 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--------------------------------------------------------------------------- gulpfile.js | 7 +++++++ lib/stats.erl | 24 ++++++++++++------------ api/somethingelse.js | 114 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ critical_api/another_thing.rb | 41 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--------------------------------------------------------------------------- webpack.js | 7 +++++-- lib/mapreduce.exs | 24 ++++++++++++------------ client/user.js | 114 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ critical/security.rb | 41 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------
  - juped 10y ago
    I know the question is rhetorical, but the answer is that many people don't understand how to use git, and the preferred way of coping with this is to dogmatically declare some git feature (either branching/merging, or the various operations that fall under "rebasing") to be "Beast. Defiler. The source of all my pain." But only people who are bad at git ever post things on the internet about git! (with the exception of Junio's blog)
alkonaut 10y ago
I think people are talking about different things. No one wants to see any "oops typo" coomits. Those are squashed/amended in the feature branch in all sane workflows. The question is only if you represent each feature with ten commits in the feature branch as one commit in master or as 2 or 3. If a typical feature starts with some cleanup/refactoring, I don't mind seeing that work separated from the new implementation in master. Some would consider a pure refactoring noise that shouldn't be in master. There seems to be an argument too that unless you have a policy of squashing completely then the outcome will be noise and not enough squashing. That depends on the people of course.
- jasode 10y ago
  >No one wants to see any "oops typo" coomits. That's what I thought but it's not quite "no one". There are some who'd love to have all git commit history, and if it was possible, the entire editor text buffer histories and keystroke logs of other programmers' work. This was my reply to it: https://news.ycombinator.com/item?id=11408221 https://news.ycombinator.com/item?id=11408221 The post I replied to qualified it with "this may be a minority position" but his comment happens to be the topmost comment so lots of HN voters agreed with him. Based on the repetition of this "git rebase" topic, I can only guess that roughly half of git users want to see all git commits with "oops, stupid typo", and the other half don't want to be inundated with meaningless noise. I really have no idea though.
  - alkonaut 10y ago
    > The post I replied to qualified it with "this may be a minority position" Madness. I did qualify my suggestion that no one wants "oops typo"-commits with "in any sane workflow" :)

npsimons 10y ago

Very much this. I keep saying: I. Don't. Care. About. Every. Little. Sneeze. A. Developer. Had. On. The. Way. To. Closing. A. Ticket. See how annoying that is? That's what it feels like to me to read non-squashed commits.

aeontech 10y ago
Why does everyone seem to insist that there's only two options? option A) SQUASH ALL THE THINGS option B) HISTORY IS SACRED AND HOLY We just make sure that the developer rebases and squashes the meandering micro-commits into parent logical units before merging. This gives us both sensible logical commits, and avoids monster commits. I spend enough time spelunking through history that I dread seeing something like this when I need to track down the context for a particular change client/something.js | 114 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ critical/something.rb | 41 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--------------------------------------------------------------------------- gulpfile.js | 7 +++++++ lib/stats.erl | 24 ++++++++++++------------ api/somethingelse.js | 114 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ critical_api/another_thing.rb | 41 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--------------------------------------------------------------------------- webpack.js | 7 +++++-- lib/mapreduce.exs | 24 ++++++++++++------------ client/user.js | 114 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ critical/security.rb | 41 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------
- juped 10y ago
  I know the question is rhetorical, but the answer is that many people don't understand how to use git, and the preferred way of coping with this is to dogmatically declare some git feature (either branching/merging, or the various operations that fall under "rebasing") to be "Beast. Defiler. The source of all my pain." But only people who are bad at git ever post things on the internet about git! (with the exception of Junio's blog)

alkonaut 10y ago

I think people are talking about different things. No one wants to see any "oops typo" coomits. Those are squashed/amended in the feature branch in all sane workflows. The question is only if you represent each feature with ten commits in the feature branch as one commit in master or as 2 or 3. If a typical feature starts with some cleanup/refactoring, I don't mind seeing that work separated from the new implementation in master. Some would consider a pure refactoring noise that shouldn't be in master. There seems to be an argument too that unless you have a policy of squashing completely then the outcome will be noise and not enough squashing. That depends on the people of course.

jasode 10y ago
>No one wants to see any "oops typo" coomits. That's what I thought but it's not quite "no one". There are some who'd love to have all git commit history, and if it was possible, the entire editor text buffer histories and keystroke logs of other programmers' work. This was my reply to it: https://news.ycombinator.com/item?id=11408221 https://news.ycombinator.com/item?id=11408221 The post I replied to qualified it with "this may be a minority position" but his comment happens to be the topmost comment so lots of HN voters agreed with him. Based on the repetition of this "git rebase" topic, I can only guess that roughly half of git users want to see all git commits with "oops, stupid typo", and the other half don't want to be inundated with meaningless noise. I really have no idea though.
- alkonaut 10y ago
  > The post I replied to qualified it with "this may be a minority position" Madness. I did qualify my suggestion that no one wants "oops typo"-commits with "in any sane workflow" :)