Skip Navigation

Posts
12
Comments
366
Joined
3 yr. ago

  • If the squash merge is too big to review then that change should have been broken up into multiple separate changes. Regardless whether you’re using pull requests or some equivalent or directly merging feature branches, if “one unit of work” is too much to review when squashed, then your unit of work is too big and needs to be split up. A unit of work should always be reviewable as a whole.

  • I constantly rebase my feature branches regardless of how many commits there are and whether I’ve pushed any of them. So long as no one else has checked out my branch it’s perfectly safe. Personally I find rebase merge conflicts far easier to work with. Traditional merge conflicts are “Here’s someone else’s changes, figure out how to merge them into your feature branch.” Rebase merge conflicts are “The main branch has changed since you made your changes. Re-apply your changes to the new base.” For me/my brain, the latter is so much easier. The only time I ever run into problems is when there are merges in the history I’m rebasing. Which I avoid by never merging into my feature branches, only rebasing.

    And if it goes wrong, just git rebase —abort. Or if you already completed the rebase, git reset —hard origin/YOUR-BRANCH. Or if you majorly fucked up, use git reflog to find a good commit and reset to that. Zero risk if you know what you’re doing.

  • I liked it ~5 years ago when it was mostly Git + project management + excellent CI. I agree that it’s gotten really messy since then. Way too many features IDGAF about.

  • Scammers spoof the caller ID. Blocking numbers doesn’t do shit because those aren’t their real numbers.

  • The tangible cost of the server it runs on and the intangible costs of the engineering time required to set up and maintain it are more than the cost of SaaS equivalents. We could but it’s a better business decision to migrate to another SaaS (since GitHub has become so unreliable).

  • I set up and maintained a GitLab instance and GitLab CI runners for five years. It was fine. I still hated it. I loath maintaining infrastructure.

  • Oh fuck off. I’m not talking about the GitLab instance. Those aren’t hard. The trauma is from other stuff, but it adds a spicy flavor of stress and anxiety to all infrastructure work.

  • It’s not as much time as it is stress, anxiety, and trauma. Being on call when shit breaks is fucking awful and my best coping strategy to date is refusing to be an infrastructure person and aggressively not giving a fuck when things are down for a day or two.

  • I'm the only person at my (small startup) company who has the skills to maintain a GitLab instance. Been there, done that, never fucking again. I HATE maintenance. We're probably going to migrate to some other platform since GitHub is intent on turning to shit.

  • What do you use for project management? What platform-less system are you using for that? Or are you saying to use a non-US platform? Do you have specifics.

  • Git allows me to write code as much as I want. But GitHub does more than just Git. If you don’t remember the details of the next task you need to work on and GitHub is down, that’s a problem. As a senior I spend a lot of time reviewing PRs. That’s considerably harder when GitHub is down.

  • Fuck around and find out

  • Why begrudgingly?

  • Codeberg isn’t viable for proprietary software

  • IMO that’s less idiomatic Go, more just plain old clearly written code. Whenever possible, the nominal (non-error) path should stay at the same level of indentation. Indentation should be reserved (as much as is possible) for loops and atypical conditions (including errors).

  • I’m still far happier with it than literally any other programming language I’ve ever used

  • 😆 yeah I didn’t read it that hard

  • I totally agree, that Go snippet is absolutely more maintainable. Though you forgot the curly braces and the semicolons are unnecessary.

  • I’ll stick with Go TYVM

  • Yes, preferring a language that’s easy to read and therefore easy to maintain over a language like Rust is definitely coping 🙄

  • Programming @programming.dev

    The Curse of Knowing How, or; Fixing Everything | Blog

    notashelf.dev /posts/curse-of-knowing
  • Experienced Devs @programming.dev

    Is GitHub Copilot worth it to you?

  • .NET @programming.dev

    What am I losing by not using the C# Dev Kit?

  • Programming @programming.dev

    Why is crypto.subtle.digest async?

  • Programming @programming.dev

    What search engine do you use?

  • Programming @programming.dev

    What scientific journals do you recommend?

  • Experienced Devs @programming.dev

    Self taught = no imposter syndrome?

  • Experienced Devs @programming.dev

    Systems engineering in the software industry

  • Programming @programming.dev

    What languages are well suited for testing SDKs written in multiple other languages?

  • Programming @programming.dev

    Why should I use rust (as a Go enthusiast)?

  • Programming @programming.dev

    How often does branchless programming actually matter?

  • Experienced Devs @programming.dev

    How do you organize miscellaneous tasks?