8 ms·

Another "I like to deliberately lose information to no benefit because I'm bad at git" 'workflow' hits Hacker News. Something is deeply wrong with the ecosyste

by juped 10y ago

Another "I like to deliberately lose information to no benefit because I'm bad at git" 'workflow' hits Hacker News. Something is deeply wrong with the ecosystem when people want to do things like this!

throwanem 10y ago
Where is information lost? Delivered branches aren't deleted, so full history information is available - it just doesn't clutter trunk by merging in every commit.
- aeontech 10y ago
  This workflow explicitly deletes delivered branches. If your workflow looks like this: - Create a feature branch - Write great code - Create a pull request against master - Get 'lgtm' through a code review - Squash merge to master - *Delete the feature branch* As far as I'm concerned, commits should be rebased and squashed into logical units on the feature branch before merge, that's the responsibility of the dev. Squashing them all into one monster commit feels like a terrible idea.
  - throwanem 10y ago
    Whoops, yeah, you're right. I was looking at the screencast and didn't see an explicit deletion, and mistook that for there not being one at all.
kiallmacinnes 10y 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)
jerf 10y ago
"bisect". Bisect becomes useless if not every commit compiles (or local equivalent). Bisect is a critical feature, even if I don't necessarily use it often, because when I need it, I need it. As long as I can bisect, I don't much care about the details. But this is definitely not compatible with three dozen commits mostly consisting of "oops didn't compile" and "forgot comma" and "fix syntax erorr". You've gotta do something about that. The way some people talk, the only acceptable history is an asciinema [1] recording of the development process with a microphone recording the developer's mutterings as it goes. The question isn't about what information you "lose" but about what you keep, because you must discard the vast bulk of it. We're arguing here about whether we chuck 99.97% or 99.99% of it. [1]: https://asciinema.org/ https://asciinema.org/
- _ikke_ 10y ago
  Bisect also becomes useless because of large commits. Even if you find the commit, the change it introduces can be so large you don't git much improvement. Git allows you to clean up your feature branches to prevent these kind of fix commits. Look at git.git. They don't require people to squash all their commits into a single patch, but still every patch should be compilable.
  - jerf 10y ago
    "As long as I can bisect, I don't much care about the details." If I can't bisect, I don't approve. So, by simple logic based on the premise you supply, I also disapprove of large commits. My point may not be what you expected prior to reading.
    - juped 10y ago
      Then your comment makes no sense in context, because you replied to my complaint that people lose information by doing these giant squash merges and having no nontrivial graph structure in their main project history.
      - jerf 10y ago

by juped 10y ago

throwanem 10y ago

Where is information lost? Delivered branches aren't deleted, so full history information is available - it just doesn't clutter trunk by merging in every commit.

aeontech 10y ago
This workflow explicitly deletes delivered branches. If your workflow looks like this: - Create a feature branch - Write great code - Create a pull request against master - Get 'lgtm' through a code review - Squash merge to master - *Delete the feature branch* As far as I'm concerned, commits should be rebased and squashed into logical units on the feature branch before merge, that's the responsibility of the dev. Squashing them all into one monster commit feels like a terrible idea.
- throwanem 10y ago
  Whoops, yeah, you're right. I was looking at the screencast and didn't see an explicit deletion, and mistook that for there not being one at all.

kiallmacinnes 10y 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)

jerf 10y ago

"bisect". Bisect becomes useless if not every commit compiles (or local equivalent). Bisect is a critical feature, even if I don't necessarily use it often, because when I need it, I need it. As long as I can bisect, I don't much care about the details. But this is definitely not compatible with three dozen commits mostly consisting of "oops didn't compile" and "forgot comma" and "fix syntax erorr". You've gotta do something about that. The way some people talk, the only acceptable history is an asciinema [1] recording of the development process with a microphone recording the developer's mutterings as it goes. The question isn't about what information you "lose" but about what you keep, because you must discard the vast bulk of it. We're arguing here about whether we chuck 99.97% or 99.99% of it. [1]: https://asciinema.org/ https://asciinema.org/

_ikke_ 10y ago
Bisect also becomes useless because of large commits. Even if you find the commit, the change it introduces can be so large you don't git much improvement. Git allows you to clean up your feature branches to prevent these kind of fix commits. Look at git.git. They don't require people to squash all their commits into a single patch, but still every patch should be compilable.
- jerf 10y ago
  "As long as I can bisect, I don't much care about the details." If I can't bisect, I don't approve. So, by simple logic based on the premise you supply, I also disapprove of large commits. My point may not be what you expected prior to reading.
  - juped 10y ago
    Then your comment makes no sense in context, because you replied to my complaint that people lose information by doing these giant squash merges and having no nontrivial graph structure in their main project history.
    - jerf 10y ago