471–480 of 546 posts
I love how the author thinks developers write commit messages. All joking aside, it really is a chronic problem in the corporate world. Most codebases I encounter just have "changed stuff" or "hope this works now". It's a small minority of developers (myself included) who consider the git commit log to be important enough to spend time writing something meaningful. AI generated commit messages helps this a lot, if de…
Earlier quoted context omitted.
> It's a small minority Is it really a small minority? I have never worked on a project that didn't have commit messages that at least tried to be descriptive (sometimes people fail at it but its very different to an outright "changed stuff"). I don't remember any friend mentioning to me them encountering a work project where the messages were totally neglected either.
Never seen that in any company I worked at either and I can’t believe professional developers seem to think that it would be ok to write meaningless commit messages. That’s just so sloppy.
Earlier quoted context omitted.
Most people and companies just use the keyboard that shipped with the computer. I don't think noise is as much of an issue as people make it out be. Marketing made up this story about linear switches being for gamers. So now every mechanical keyboard needs to make unnecessary noise and offer extra resistance for harder bottom out or you're not a serious typist. But that's not inherent to the keyboard. Linear switches…
I'm not a gamer these days, but from what I've seen, the gamers like a different type of keyswitch than regular typists. Normal typists like a clicky keyswitch where it clicks with very little travel, and has plenty of travel after this to avoid bottoming out. (so, Cherry blue) Gamers want mechanical keyswitches with no click at all. (Cherry brown I think)
The most popular type of switch is brown because it's essentially a linear switch that is not marketed towards gamers. It's just sad.
Earlier quoted context omitted.
Most people and companies just use the keyboard that shipped with the computer. I don't think noise is as much of an issue as people make it out be. Marketing made up this story about linear switches being for gamers. So now every mechanical keyboard needs to make unnecessary noise and offer extra resistance for harder bottom out or you're not a serious typist. But that's not inherent to the keyboard. Linear switches…
I find the resistance to be a hindrance when typing. Fastest typing speed and comfort for me is my thinkpad keyboard which uses scissor switches with a very low profile - you need less effort per keystroke!
Low profile scissors are a compromise. They are tactile but it's for once functional as it compensates for the obvious lack of travel. The result is a mediocre but still above average experience. You can type fast on them but with more fatigue than high-profile linear.
Marketers want you to believe there's at least three different distinct switch types for different purposes because they want to sell you the same keyboard twice or thrice. But in reality there's linear and stupid. And some of them make unnecessary noise. Some of them make really sweet nostalgia noises like Alps switches but it's still a worse typing experience.
Earlier quoted context omitted.
We do. If we are building out a feature, none of its code is merged into main until it is complete (if this is a big feature, we milestone into mergeable and releasable units). The feature is represented by a Story in Jira and a feature branch for that story. Subtasks in jira are created and multiple developers can pick up the different subtasks. There is a personal branch per subtasks, and PRs are put up against the…
I get your POV, but I’ve always considered that long-lived branches in the canonical repo (the one in the forge) other than the main one should be directly related to deployable artifacts. Anything else should be short-lived. There can be experiment on the side that warrants your approach, but the amounts of merge going back and forth would make this hard to investigate (especially when blaming) I would prefer to hav…
Blame, bisect etc. work well with histories with lots of back-and-forth merging, as can be easily seen in Linux, so blaming is definitely not a reason not to do it this way if your project calls for it otherwise. Perhaps one issue with such workflow is that some popular review tools aren't exactly great at letting you review merge conflict resolutions.
Jujutsu equivalents, if anyone is curious: What Changes the Most jj log --no-graph -r 'ancestors(trunk()) & committer_date(after:"1 year ago")' \ -T 'self.diff().files().map(|f| f.path() ++ "\n").join("")' \ | sort | uniq -c | sort -nr | head -20 Who Built This jj log --no-graph -r 'ancestors(trunk()) & ~merges()' \ -T 'self.author().name() ++ "\n"' \ | sort | uniq -c | sort -nr Where Do Bugs Cluster jj log --no-grap…
Let's NOT jump to conclusions; it could mean many things. For example, a period with other priorities, different urgencies, other issues external to the project itself and beyond our control, vacations, illnesses, or anything else that could impact the commit history.
I think these considerations and the others expressed in this article can easily lead to hasty conclusions and erroneous deductions, too simplistic.
Coding flow, like business needs, cannot always be objectively and deterministically measured.
Earlier quoted context omitted.
It's the dvorak of git... Maybe more efficient but incompatible with everyone else and a very loud vocal minority. You can find this pattern again and again. How many redditors say 120fps is essential for gaming or absolutely require a mechanical keyboard?
Yeah I think that dvorak is a good example, too. I don't get the mechanical keyboard one, though. I am fine with any keyboard, I just like my mechanical keyboard at home. Just like I am fine with any chair, but ideally I would have a chair I like at home. 120fps I have no experience with, but I would imagine it's closer to video quality. Once you're used to watching everything in 4K, probably it feels frustrating to…
I love my Aeron chair. I've had it for fifteen years and it's still in great shape.
I used to have chronic back pain. Getting good ergonomics at home really put that to bed.
Jujutsu equivalents, if anyone is curious: What Changes the Most jj log --no-graph -r 'ancestors(trunk()) & committer_date(after:"1 year ago")' \ -T 'self.diff().files().map(|f| f.path() ++ "\n").join("")' \ | sort | uniq -c | sort -nr | head -20 Who Built This jj log --no-graph -r 'ancestors(trunk()) & ~merges()' \ -T 'self.author().name() ++ "\n"' \ | sort | uniq -c | sort -nr Where Do Bugs Cluster jj log --no-grap…
Saw all the replies crying over how verbose these are, clicked through to TFA expecting to see simpler commands. Nope, they're basically the same thing, just slightly shorter. I would never memorize either the jj or git versions if I planned to use them regularly; I'd make aliases.
Earlier quoted context omitted.
I don’t understand how people can remember all these custom scripting languages. I can’t even remember most git flags, I’m ecstatic when I remember how to iterate over arrays in “jq”, I can’t fathom how people remember these types of syntaxes.
jj's template and revset languages are very simple syntactically, so once you're comfortable with the few things you do use often it's just a question of learning about the other existing functions (even if only enough to know to look them up), which slot right in and compose well with everything else you know (unlike flags which typically have each their own system). Or, perhaps better yet, defining your own functio…