Usable icons _are_ a bit interesting. A bunch of same shapes with same-ish colors on a grid is NOT prioritizing usablity. It's prioritizing minimalism. The middle icons in that list are interesting enough that your visual cortex can pattern-match to your previous experience selecting that app without much conscious effort. The oldest is a bit much but at least still recognizable (not necessarily "well known", that's different), but the new ones are worse: so boring and generic that it takes actual conscious effort to select them from a sea of sameness.

I don't think skeuomorphism applies to icons. The early pen-and-inkpot icon isn't trying to act/feel like a pen and inkpot. It's not like there is an inkpot in the program's UI and you have to move the cursor to it every once in a while to keep typing. It's just a very unique and recognizable symbol to indicate which program is which.

On the command line it would be "Pages", something fairly meaningful. The equivalent to the latest icon on the command line would be just calling it "P". And then everytime you want to launch it you must select which P program you want among all the others; equivalent to searching the launcher for which "black blob with a couple orange lines on it" you want.

I have a feeling the icons tried way too hard to trend toward "minimal", but minimal is not the same as bland generic blobs like the latest ones are (and not just Apple, generic icons claiming to be minimal are everywhere). The middle one seems to be the best of both: fairly minimal, still unique, still indicates "writing", as opposed to either end which both seem to be more about the pen itself and would be better suited to an icon for the Apple Pencil section of Settings.

All of the pen-only ones are terrible for something called Pages, the middle-to-older page-based ones actually fit the brief.

You don't need to store the timezone anywhere, you just need to know the current local timezone when the stored UTC time is used. And that's why storing in UTC is better, because it only takes one conversion to represent it in some arbitrary local time.

If you stored it as a local time (ie: with TZ), then if it's ever later translated to a different local time (different TZ), you're now dealing with all the quirks of 2 different timezones. It's great way to be off by some multiple of 15 minutes, or even a day or two!

Heck, even if it's the same exact location, storing in local time can still require conversion if that location uses daylight savings! You're never safe from needing to adapt to timezones, so storing datetimes in the most universal format is pretty much always the best thing to do.

I think you got it backwards. The only way is guessing, it's all random.

It's the internal inconsistencies that get me. Like, OK, I understand that there might be some quirks, maybe due to some weird backwards compatibility or technical limitation, but there are multiple incompatible quirks _inside_ this single interface! It's terrible, and things like this are a huge part of the reason JS was long considered (and sometimes still is) a Not So Good language.

"There's no reason a local copy should have the exact same implementation as a repository, git made a wrong turn in this."

Who is forcing you to keep a local copy in the exact same configuration at upstream? Nothing at all is stopping you from applying your style to your repos. You're saying that not being opinionated about project structure is a "wrong turn"? I don't think so.

I think most "ground truth" open-source repos do end up operating like this. They're not letting randos push branches willy-nilly and kick off CI. Contributors fork it, work on their own branches, open a PR upstream (hence that name: PULL Request), reviews happen, nice clean commits get merged to the upstream repository that is just being a repository on a server somewhere running CI.

This.

"If you do a single rebase at the end, there is nothing to remember, you just get the same accumulated conflicts you also collectively get with frequent rebases."

There is _everything_ to remember. You no longer have the context of what commits (on both sides) actually caused the conflicts, you just have the tip of your branch diffed against the tip of main.

"Hence I don’t understand the benefit of the latter in terms of avoiding conflicts."

You don't avoid conflicts, but you move them from the future to the present. If main is changing frequently, the conflicts are going be unavoidable. Why would you want to wait to resolve them all at once at the very end? When you could be resolving them as they happen, with all the context of the surrounding commits readily at hand. Letting the conflicts accumulate to be dealt with at the end with very little context just sounds terrifyingly inefficient.

If you rebase form main often, it keeps the difference to main quite small, so that when it comes time to do the final merge to main, it's either able to be fast-forwarded (keep it linear, good job!), or at least a very low risk of being conflicted (some people like merge commits, but at least your incoming branch will be linear). Because even though you might have commits that are a year old, initially branched from main from a year ago, their "base" has gradually become whatever main is _now_.

It's just like doing merges _from_ main during the lifetime of the branch. If you don't do any, you'll likely have lots of conflicts on the final merge. If you do it a lot, the final merge will go smooth, but your history will be pretzels all the way down.

In other words, frequent rebasing from main moves any conflicts from the future to "right now", but keeps the history nice and linear, on both sides!

A merge can have you doing a history quiz as well. Conflicts can occur in merges just as easily as rebases. Trouble with trying to resolve conflicts after a big merge is that now you have to keep the entire history in your head, because you don't have the context of which commit the change happened in. With rebase you'd be right there in the flow of commits when resolving conflicts.

I'd be willing to bet most devs do something like this, or wish they could be doing it, but don't know about rebase or are scared of it. However, that might be because they're only thinking about rebase as OP's article uses it: only as an alternative to merge for get changes from another branch.

Interactive rebasing to write local history on your working branch is incredibly useful, but also doesn't have anything to do with the "rebase vs merge" conundrum, and as long as you're not pushing to a shared branch, it doesn't have much to do with "erasing other's history".*

If you can look at a working branch (with more than a trivial addition or fix) and not feel the need to do a interactive rebase (once you know how) before making a PR, then you're either a magical 100x unicorn dev that makes every commit the perfect commit, or you cheated and made a new branch and cherry-pick-squashed your way to a clean history.

"Here’s the thing: the worst case scenario for a rebase gone wrong is that you delete your local clone and start over. That’s it. Your remote fork still exists. The main repository still exists."

You forgot "your backup local branch still exists". Branching in git is effectively free, just duplicate the one you're worried about rebasing: if the rebase goes wonky enough that you can't cleanly abort it, you just start over on the backup branch, making another duplicate and trying again.

It also gives you a nice reference to compare the results of the rebase with your original intentions for the code.

Oh, I guess you kinda did address is, with pushing to your remote fork.

But why push? Rebasing a branch doesn't affect any other branches, so a local backup branch is just as safe as a branch on the remote fork. You shouldn't ever need to nuke your clone unless you're trying something silly like rebasing main (without a local backup branch!), or doing more than just rebasing, like messing with the reflog.

Also, I don't think it's rebasing that scares people, it's the force push that scares people. There is so much out there saying "never force push or all the trees in a 500 mile radius will spontaneously combust" without explaining the nuances of concurrent work on shared branches vs a personal fork used for making contributions upstream, nor the "safety" of force-with-lease. For the latter (fork for contrib), just yolo it: you're the only one working on your fork!