tatterdemalion @ tatterdemalion @programming.dev

Professional software engineer, musician, gamer, stoic, democratic socialis

---

Read more

Posts

6

Comments

528

Joined

2 yr. ago

It's surprising how Github is sorely lacking in git features and even encourages bad practices.

1. There is only a linear history view of commits without any child/parent relationships visualized. I have coworkers that tell me it's annoying how I use merge commits because they just see a big list of small commits in the history, and they'd rather see one commit per PR. Well... I sympathize, but also, fuck that! I'm not squashing my carefully crafted commits because Github has a shitty UI. Use git log --first-parent or something like lazygit. It's sad that many open source projects have adopted a "squash and merge" mantra for PRs. All of the merge methods have a valid use case, but people are so beholden to the damned Github history view.
2. PRs have no concept of what a patch is. If you rebase, the entire history disappears. Reviewers cannot see changes made to individual patches unless they are applied first in new commits and then manually squashed into old patches after the review is done. Phabricator does this better IMO; each patch has its own history. I've even heard devs at other companies tell me they never make PRs bigger than 100 LOC. That just seems like a huge waste of time to me, unless you have some special tools to support that bizarre workflow.
3. Merge queues only support a single merge method, one of merge commit, rebase, or squash. So we just don't use this desirable feature because of this limitation.

Or use a tool like StackedGit which makes the atomic commit workflow incredibly simple. Build atomic commits as you go instead of after you've written all of the code.

If you need a whole meeting to explain what's going on in your PR then it's already too complicated, IMO. That explanation should be done as a combination of PR description, commit messages, documentation, comments, and the code itself.

Everyone will forget a meeting. The stuff I described will pay dividends for future maintainers.

The meetings should happen at design and planning phase.

Even though the "open" option would only allow Threads accounts to post via mention, I am still concerned about bots. I imagine as soon as bot owners find out they can get access to more views via federation, they will spam as many instances as they can get away with.

So I am voting at best "limited" to curtail spam in the feed. I am less concerned about spam in the comments because it will hopefully get downvoted. But who knows, bot accounts may be upvote farming.

I am split between "limited" and "blocked" at the moment. I don't mind real Threads users being able to subscribe and comment, but bots make me worry.

Define "program"

Yea except serverless you pay for usage, so if you have zero users, it's free! Just make sure you put a hard limit on autoscaling.

At this point when someone says "soul" I just think of ego/personality. No I don't think it exists outside of our physical world. No I don't think it "goes somewhere" when we die. I also don't think "free will" is a well-defined or useful concept.

Glove80

I had to get a split keyboard to alleviate pain in hands and chest.

Your Git requires a regular flagellation to function properly.

Pays to know how to recover code from the reflog in these cases.

The git push --force is definitely a controversial suggestion, im personally happy with doing that, but I have also personally accidentally force pushed dev/main and seen others do it. Squash on merge is probably a safer habit to have. Also, gitlab and bitbucket both get a bit confused if you forcepush to a branch that is part of a MR.

You can add branch protections that will prevent you from accidental force pushing to main or dev.

IMO when I see a PR with "WIP" commits, I just assume that minimal effort was put into keeping the commits organized, and I squash all commits to review the PR. If I see many meaningful commit messages, I will try reviewing one commit at a time.

When I make a PR, I force push to keep my commits organized. If there are changes I want to make as a result of feedback, and they would create significant churn to rebase all of the patches, then I will apply the feedback in a follow-up commit.

Boo paywall

Book a night at Trump Tower.

And then when you get good enough you can consume music you like while also learning to play it at the same time. One of my favorite relaxing yet also stimulating activities.

I literally didn't even boot Windows for a month and then when I did, I got BSOD on boot, and it gave me some bullshit about not being able to find a device. How's that for maintenance? I can't say I miss it.

Yea I should have clarified. Prototypes are a great idea. The problem occurs when you say, "this is good enough we can improve on it as we go." Yea good luck balancing priorities when everything breaks from tapping your keyboard too hard. You MUST NOT MERGE the prototype.

That a "working" prototype with no tests is just as good as a carefully-designed and well-tested feature. I see this happen so often that a coder puts a prototype in front of a product manager or exec and they are like, "this is exactly what we need, now! Ship that!" And then misery ensues for all of the engineers that need to maintain this piece of garbage. As managers pressure the engineers to build new features on top, they inevitably break fundamental parts of it, and without a confident leader to demand that tech debt is paid off, that product will consume the souls of many desperate coders.

In contrast, if you do it right the first time, there will be significant parts of code that never need to change, and the parts that do need to change will be much easier, because it will be obvious if it breaks the tests.

Sadly it doesn't support reporting income from independent contracting (yet).

Could you be any more of a morale killer?

Anti-antifa does not subscribe to the law of the excluded middle, so double negation elimination does not apply.

EDIT: This was a math joke, but I'm proud that it seems to have gone over so many heads.