Having the same experience. My kids enjoy getting new sets, but most of them are quickly customized or just destroyed to build something completely new. Terrible take in the parent.
While I agree with the spirit of the thread and dearly love my mini, I think this reasoning doesn’t account for a substantial reduction in bezels: my iPhone 5S had more than a centimetre of black bars above and below its 4" display (altogether it was 5.4" in diagonal), I bet those phablets you mentioned had even bigger bezels and were closer to modern 8.5" phones.
France doesn't even have a nuclear triad in place, and last time they offered any big assurances at the international level Munich '38 happened and then June '40. Macron and the people running the French State are well aware of this, no matter their public statements.
I fail to see how the inane failures brought by a dysfunctional IVth Republic are in any way relevant to the post-WW2 world order where both nuclear weapons and the EU began to exist, and in which France has been extremely relevant multiple times over, both geopolitically and on operational theatres.
The importance of the land component of the triad is vastly overstated, simply do not make sense at the landmass size of France, and only matters when your doctrine is USA vs USSR cold-war era complete retaliatory annihilation anyway.
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.
hy3?
https://github.com/outfoxxed/hy3
(I'm an ex i3/now sway user and hy3 is the only way I can bear using hyprland)
reply