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!
Something is deeply wrong with the ecosystem when people want to do things like this!
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.
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.
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.
Note also that many other commits that could not build did not contain the bugs ;-)
(Speaking of luck, I worked with a codebase where the bug was always inside a jumbo commit involving at least a hundred of files)
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.
See how annoying that is? That's what it feels like to me to read non-squashed commits.
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 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------But only people who are bad at git ever post things on the internet about git! (with the exception of Junio's blog)
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.
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
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.
Madness.
I did qualify my suggestion that no one wants "oops typo"-commits with "in any sane workflow" :)
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*