expr

@expr@programming.dev

This profile is from a federated server and may be incomplete. Browse more on the original instance.

expr,

I don’t want squashed commits. It makes git tools worse (git bisect, git cherry-pick, etc.) and I work very hard to craft a meaningful set of commits for my work and I don’t want to throw all of that away.

But yeah, I don’t actually give a shit what they are doing on their branches. I regularly rebase onto master anyway.

expr,

Nope, you just need to do it once: git-scm.com/book/en/v2/Git-Tools-Rerere.

expr,

ITT: people who have no idea how rebasing works.

expr,

This a really bad take and fundamentally misunderstands rebasing.

First off, developers should never be committing to the same branch. Each developer maintains their own branch. Work that needs to be tested together before merging to master belongs on a dedicated integration branch that each developer merges their respective features branches into. This is pretty standard stuff.

You don’t use rebasing on shared branches, and no one arguing for rebasing is suggesting you do that. The only exception might be perhaps a dedicated release manager preparing a release or a merge of a long-running shared branch. But that is the kind of thing that’s communicated and coordinated.

Rebasing is for a single developer working on a feature branch to produce a clean history of their own changes. Rebasing in this fashion doesn’t touch any commits other than the author’s. The purpose is to craft a high quality history that walks a reader through a proposed sequence of logical, coherent changes.

Contrary to your claim, a clean history is incredibly valuable. There’s many tools in git that benefit significantly from clean, well-organizes commits. git bisect, git cherry-pick… Pretty much any command that wants to pluck commits from history for some reason. Or even stuff like git log -L or git blame are far more useful when the commit referenced is not some giant amalgamation of changes from all over the place.

When working on a feature branch, if you’re merging upstream into your branch, you’re littering your history with pointless, noisy commits and making your MR harder to review, in addition to making your project’s history harder to understand and navigate.

expr, (edited )

Or, you know, on your own feature branch to clean up your own commits. It’s much, much better than constantly littering your branch’s history with useless merge commits from upstream, and it lets you craft a high-quality, logical commit history.

expr,

Yeah it is something people should take time to learn. I do think its “dangers” are pretty overstated, though, especially if you always do git rebase --interactive, since if anything goes wrong, you can easily get out with git rebase --abort.

In general there’s a pretty weird fear that you can fuck up git to the point at which you can’t recover. Basically the only time that’s really actually true is if you somehow lose uncommitted work in your working tree. But if you’ve actually committed everything (and you should always commit everything before trying any destructive operations), you can pretty much always get back to where you were. Commits are never actually lost.

expr,

I was replying to the other comment, not yours. Though there’s not really a way of using rebasing without force pushing unless it’s a no-op.

Rebasing is really not a big deal. It’s not actually hard to go back to where you were, especially if you’re using git rebase --interactive. For whatever reason people don’t seem to get that commits aren’t actually ever lost and it’s not that hard to point HEAD back to some previous commit.

expr,

Ah gotcha.

like to rebase after fetching and before pushing. IMO that’s the most sensible way to use it even in teams that generally prefer merge.

What do you mean? Like not pushing at all until you’re making the MR? Because if the branch has ever been pushed before and you rebase, you’re gonna need to force push the branch to update it.

Personally I’m constantly rebasing (like many times a day) because I maintain a clean commit history as I develop (small changes to things I did previously get commits and are added to the relevant commit as a fixup during interactive rebasing). I also generally keep a draft MR up with my most recent work (pushing at end of day) so that I can have colleagues take a look at any point if I want to validate anything about the direction I’m taking before continuing further (and so CI can produce various artifacts for me).

It’s also not obvious to beginners since pull is defaulted to fetch+merge.

Yeah, pull should definitely be –ff-only by default and it’s very unfortunate it isn’t. Merging on pull is kind of insane behavior that no one actually wants.

expr,

I mean, you’re scapegoating developers right now. Developers don’t determine priorities. That’s a product/business direction problem.

Also, UX doesn’t get to say what is hard to do or not (that’s the job of a developer, you really don’t have any way of knowing without familiarity with the implementation details), so that’s certainly at least part of your problem right there.

expr,

No, because raw-dogging JavaScript isn’t something grown-up software shops do.

expr,

Let’s not get wrapped up in wild conspiracy theories like Republicans are so prone to do. No one is intentionally doing this. It’s poor regulation, oversight, and controls. Simple as that.

expr,

This whole situation just emphasizes the fact that rebasing >>>>>>>>>> merge squashing.

expr,

I’m sorry but how in the hell is this in any way related to ADHD? ADHD doesn’t make you fixate on some future events all day unless you’re like, super excited about it or something I guess. In fact, it’s often the opposite, getting fixated/distracted by other things and ending up late to meetings if you’re not careful. ADHD is a very specific disorder of executive function and while it can manifest in a variety of ways, there’s always an underlying mechanism behind it that makes some kind of sense. It’s not a blanket “oh I can’t manage any responsibilities haha”.

Seriously, people these days will just lump every little thing in with ADHD and it drives me crazy. I have had (actually diagnosed) ADHD my whole life (way before all this self-diagnosis nonsense on Tiktok) and have learned a variety of strategies for managing it. It’s posts like this that make it difficult for people who actually do have ADHD, because it makes people confused about what it actually is and what it’s actually like to live with. ADHD is not a Boogeyman you can blame all your problems on and treating it as such does a huge disservice to people that actually have the condition.

/rant

expr,

If you’re working with csv data, www.visidata.org >>>>> excel (assuming you’re comfortable with terminal UIs, anyway). You can very rapidly slice and dice data and for formulas and such, you can just write Python.

expr,

I mean, it still doesn’t change the fact that no one actually wants this shit.

expr,

Could you not have a hashmap keyed on matches pointing to vectors of strings for the players in each match? Basically modeling the data how you want rather than relying on indexing.

expr,

If you instead made your lobby field a HashMap<String, MatchId>, then whenever you get an event from a known player, you can lookup the match they are in from the lobby map and use that to lookup other data about the match (such as the other players) via the matches field (assuming that was also changed to be a hashmap as described in my previous comment).

expr,

Nope, based on the user’s comment history, they’re a conservative nutjob.

Android users who have a keen eye for design and detail, how is the whole stutter/lag situation? Esp. after a few years of use?

I haven’t used an Android device since my last one, the Galaxy S8. Beautiful hardware, beautiful design, but it was plagued with animation stutters and dropped frames. I switched to an iPhone and an iPad around 6 years ago. And the animations were buttersmooth. It was almost unthinkable to achieve such a fluid interface on any...

expr,

My pixel 7 pro is perfectly smooth and seamless. Oh and voice assistant is far faster than anything on iPhone thanks to the on-board Tensor chip.

expr, (edited )

I definitely associate “ninja” with wannabe JavaScript developers.

Pureblood is pretty funny, though of course we actually use Haskellers. Honorable mention goes to “Haskellnaut” to (playfully) describe taking the language as far as it can go.

expr,

Also not going to happen. It’s massively overrated.

expr,

In my experience all terms are used pretty interchangeably (well, rarely programmer or coder, I guess), though I prefer software engineer.

expr,

It’s perfectly stable. Linux just generally attracts people who like to tinker and tweak things, in particular because it’s much easier to do and gives you a lot of power and flexibility in making the machine your own.

My laptop running Arch Linux has remained problem-free for the last 6 years or so since I installed it.

expr,

The software is pretty overrated. Especially safari, which is a legitimately terrible browser and has been for a long time.

expr,

Umm, you can do that on any device. It’s called Google Meet, Zoom, Discord, or any other countless othe video chatting applications out there.

Apple software is pretty overrated no matter if it’s iOS or macOS. I use a MacBook for work and I use exactly zero Apple apps because they just aren’t very good.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • JUstTest
  • mdbf
  • everett
  • osvaldo12
  • magazineikmin
  • thenastyranch
  • rosin
  • normalnudes
  • Youngstown
  • Durango
  • slotface
  • ngwrru68w68
  • kavyap
  • DreamBathrooms
  • tester
  • InstantRegret
  • ethstaker
  • GTA5RPClips
  • tacticalgear
  • Leos
  • anitta
  • modclub
  • khanakhh
  • cubers
  • cisconetworking
  • provamag3
  • megavids
  • lostlight
  • All magazines