In 25 years of professional development I have several counter examples where some bit was either a trivial git revert of a single commit - among multiple ones in a branch - away, or an absolute pain because the squash-merge commit had flattened too many concerns together, concerns that were perfectly split in the topic branch but that branch was long gone by virtue of being auto-deleted on PR merge.
Coincidentally, every single squash-merge commit advocate I've had the unfortunate debate with was a regular practitioner of public tmp / tmp / try again / linter / tmp / fix / fix / haaaaaands commits.
Note that I'm not against squashing/history rewriting e.g rebase -i and stuff (which I'm a heavy user of so as to present sensible code aggregation reviewable per-commits), only squash-merge.
I take it you haven't had the pleasure of working with your average ("dark matter" as they're called here) developers. I wouldn't call myself an "advocate" of squashes, but it's often the only practical way of keeping git history somewhat usable when working with people who refuse to learn their VCS properly.
I chunk my changes into tiny commits ("linter"/"tmp"/"wip"), but then rebase aggressively, turning it into a set of logical changes with well-formed commit messages. git bisect/revert work great with history written in this way even years layer.
But: most of the people I've been interacting with also produce lots of "wip"/"tmp", but then skip the rebase. I can only offer my help with learning git rebase for so long before it starts taking too much time from the actual work. So squash it is: at least it produces coherent history without adding thousands of commits into `--ignore-revs-file`.
And sometimes, a patch is just that big. especially in UI works where a single change can cascade down to multiple layers.
> I chunk my changes into tiny commits ("linter"/"tmp"/"wip"), but then rebase aggressively, turning it into a set of logical changes with well-formed commit messages. git bisect/revert work great with history written in this way even years layer.
In a PR based workflow, it has become easier to have the PR be a logical unit than to `rebase -i` all the time on my end.
If you work with a ticket system, squash-merge gives you the same granularity, where a commit would refer to a single ticket.
A ticket should be atomic describing a single change request. PR in this case are the working room. It can be as messy or as clean as you want. But the goal is to produce a patch that introduces one change. Because if you would rebase -i at the end, you would have a single commit too in the PR.
No, you wouldn't. git rebase -i is to remove noise, which is about merging commits that, well, make more sense together than apart. Which is mostly about summarizing trivialities (e.g. several typo fixes) and squashing fixups into commits that introduced a problem in the same branch.
A typical bugfix branch might look like this after rebase -i:
Those looks more like noise to me. A squashed merge (or a final squash before PR) would be:
TN 43 - Fix mismatched interface between Foo and Bar
We've moved the X property to a more appropriate place and
improved the documentation for Feature Foo. We've also found and fix
an O(n^2) implementation in feature Bar.
The the ticket TN-43 will have all the details that have lead to the PR being made: Bug reports, investigations, alternative solutions,...
The commit message is what's more important. I don't think I've ever needed what is in a merged branch. But I've always wanted the commit at one point to have tests passing and a good description of the patch. And all the talk in the engineering team are always about ticket. It does makes sense to align those.
They aren't noise at all and have found them useful a bunch in the past when I worked at a place that didn't squash. Commits at this level act as immutable comments that don't get out of date. Provided you do --no-fast-forward merges, the merge commit is the feature commit and you can get the "clean" feature history with `git log --merges --first-parent`. Best of both worlds! Being able to `git blame` and get a granular message about why something was done can be really handy, especially when looking unfamiliar code.
I get where you came from, but I prefer having a more holistic view of a change, especially from a product perspective. So even when git-blaming, either I’m reading the current file or I go straight to the log of the commit (with message and diff).
I prefer granularity at a product or team level decision. Not workflow details.
I'm not trying to convince you to adopt or anything, but I'm saying you can have all of that without squashing with the caveat that you would need an alias to jump to the merge commit. Otherwise, you just treat merge commits as you would a squash one. Merge commits are just like regular commits that can have a custom message and show a diff.
> If you work with a ticket system, squash-merge gives you the same granularity, where a commit would refer to a single ticket.
With GitHub you can squash any PR merge. The link to the PR will include the complete history of the feature branch prior to the merge. Even the commit history prior to force pushes is tracked.
> No. Human light perception works on a log scale, allowing us to maintain useful vision over 6 orders of magnitude of luminance, from the sun at noon to moonless nights, whereas halving is .3 orders of magnitude. In relative terms, halving light is a tiny blip of the dynamic range of vision.
Kind of missing the point that:
a) a display emits spectacularly less light than the sun, even on very overcast days
b) said "blue light" reduction is presumably intended to happen at night where 1) any comparison with the ability to maintain unsaturated vision in plain sun on a clear day is largely irrelevant and 2) backlight itself is typically lower than in daylight (not for OLED which does PWM)
So given that the amount of artificial light to not screw up with sleep is about equal to "none at all" I'll take a cut in half of what essentially constitutes a flashlight aimed straight at my retinas any day.
> Here are four things that can help. [...] Use dark mode [...] found reductions in luminance ranging from 92% to 98%! That’s huge.
From my anecdotal experience dark mode and other low contrast themes are mostly used by people who set their brightness too high, and conversely people switching to dark mode immediately crank brightness up.
Hmm that might be nice actually. I like not conflating those two things, but as you say if the repo is already init'd then there's no chance it'll be used for the wrong purpose.
In any case the main thrust was just to avoid embeddings assumptions about branch names in your scripts :)
It simply occurred to me that if your `user.defaultBranch` is set to e.g `trunk` then presumably when you `git init` you also want it to create a `trunk` branch, ergo `init.defaultBranch` would be set to the same value, ergo... irrespective of naming, could they actually be the same thing?
I can see a case for keeping them apart too though.
I've had essentially that - if a bit fancier to accept an optional argument as well as handle common "mainline" branch names - aliased as `git lint` for a while:
> Hourglass. A subject would fall into this shape category when there is a very small difference in the comparison of the circumferences of her bust and hips AND if the ratios of her bust-to-waist and hips-to-waist are about equal and significant (Simmons, 2002)
> Rectangle. A rectangular subject would have her bust and hip measure fairly equal AND her bust-to-waist and hip-to-waist ratios low. She would not possess a clearly discernible waistline (Simmons, 2002)
Over here (E.U) I'd say most women definitely would be "hourglass shaped" in some way more than any other shape - maybe some would be a tie with "rectangle" but I'm breaking the tie by saying it's fair to say hourglass does not mean wasp-waist either - so I couldn't reconcile my anecdotal observation from the stated facts until it dawned on me that this was U.S stats.
> One 2007 study found that half of women (49%) in the U.S. were considered rectangle-shaped. Only 12% of women had a true hourglass figure.
> Results from the 2007–2008 National Health and Nutrition Examination Survey (NHANES), using measured heights and weights, indicate that an estimated 34.2% of U.S. adults aged 20 years and over are overweight, 33.8% are obese, and 5.7% are extremely obese.
And apparently it's worse for women (35.5% obese) than men (32% obese).
Anyway I'm not sure what "true hourglass" is supposed to even mean (wasp-waist?); according to the definition you got some waistline + balanced hip and shoulders => you're hourglass. If you start using "rectangle" as a fallback when in doubt then of course it's going to rate higher.
Funnily enough the very study linked is a comparison with another country (Korea):
For far too long I'm ashamed to admit, I would use vim with the adventure time theme on iterm2. Looking at it now I'm shocked my eyes didn't bleed more. I think the worst part was that visual mode was neon yellow bold text with neon pink bg. Relying on visual mode quite a bit while using vim I was self inoculating my subconscious with stills of a poor Jackson Pollock imitator while on multiple different amphetamines. Hopefully I find out my resistance soon.
I loved the Blades dashboard. Something about idly pressing the shoulder buttons to flip through the blades while talking to my friend with that goofy wireless "Xbox communicator" on my ear.
Because at some point it becomes cheaper to ship and destroy than to store and sell.
Inventory is "dead money" in accounting books!
Money has been converted to Obtainium and Obtainium just sits there until it is converted back to (hopefully more) money, taking valuable space that could be filled with more Obtainium as soon as it goes away.
At some point that Obtainium sitting there unsold just becomes un-space and destroying it becomes the cheapest move.
Probably you should really watch TNG first, lots of characters and lore that would be needed to fully appreciate a lot of things that would otherwise fall flat at best or be outright not understandable. I don't think they matter to understanding the main arc but then the main arc is only a small part of the show.
(Voyager is entirely optional but a much welcome addition that happens concurrently at later seasons; I would recommend it on its own anyway.)
For all these shows, let them grow on you, the first season of each can be a bit awkward but then things start to fall into place, both in terms of characters/lore/setting/story/world building as well as actors themselves getting the hang of characters.
And yes there are absolute duds of episodes, but don't let that make you miss the absolutely fantastic ones.
Not knowing the established history of some characters can actually be nice I think. The difference between a blank slate with conveniently made up background and a background that has already been told, in quite some detail, that difference tends to be very noticeable. No matter how "complex" the background made up on the spot is.
When the background has been told elsewhere, it's a legitimate challenge to the unprepared viewer's mind. But when it's made up on the spot, it's an arbitrary riddle. I know some viewers love that kind of stuff (e.g. everybody who made it through Lost I guess?), but to me that just feels annoying. If you want me to apply myself to the riddle, make it part of the story (like in a whodunnit), or don't keep me guessing.
But when it's organically grown background complexity from another story, I'm perfectly fine with it. Patrick Stewart's Gurney Halleck: he just pops up later with atomics, the "how" is not part of the movie adaptation. And neither is speculating about it. It's just an obvious indication that yes, there's more happening in this universe than the part squeezed into anamorphic cinemascope.
That being said, yes, watching TNG after DS9 wouldn't work well at all. It's hard enough watching early episodes after late episodes, because even the "adventure of the week" episodes have been told very differently later, but the universe is too much the same to really disconnect.
Starfleet's relationship with the Cardassians was established in TNG, and I think that DS9 failed to reiterate that properly in the first season.
Then you have Obrian's history with the Cardassians - quite significant for his new assignment and without this context the character feels like a fake tough guy. The acting and directing was brilliant, because we could feel the restrain, but without understanding this it comes off cocky. It's like watching Travolta's character dance poorly in Pulp Fiction - if you didn't know who Travolta was, the scene comes off poorly acted. Or Robin Williams playing a gay man playing straight. Some background of the character is important to actually enjoy the acting mastery that we are witnessing.
Coincidentally, every single squash-merge commit advocate I've had the unfortunate debate with was a regular practitioner of public tmp / tmp / try again / linter / tmp / fix / fix / haaaaaands commits.
Note that I'm not against squashing/history rewriting e.g rebase -i and stuff (which I'm a heavy user of so as to present sensible code aggregation reviewable per-commits), only squash-merge.
reply