371–380 of 546 posts
Earlier quoted context omitted.
I rebase stacked diffs all the time so jj makes my life so much easier because its rebasing is much more ergonomic than git.
this seems very easy in git tho how much easier can it get, do you have an example of each of them?
Earlier quoted context omitted.
If your goal here is to have linear history, then just use a merge commit when merging the PR to main and always use `git log --first-parent`. That will only show commits directly on main, and gives you a clean, linear history. If you want to dig down into the subcommits from a merge, then you still can. This is useful if you are going back and bisecting to find a bug, as those individual commits may hold value. You…
Git bisect is one of the important reasons IMO to always squash-merge pull requests: Because the unit of review is the pull request. I think this is all Github's fault, in the end, but I think we need to get Github to change and until then will keep using squash-merges.
Earlier quoted context omitted.
this seems very easy in git tho how much easier can it get, do you have an example of each of them?
Git rebases don't work if there are conflicts, jj doesn't have this problem. Also idk if you can rebase onto multiple parents with git but jj can do it.
If I change a line of code several times and rebase on to a branch that changed the same lines of code, how are you sure what the right one is?
Earlier quoted context omitted.
This is a team lead/CTO problem. A good leader will be explicit in their expectations that developers write good commit messages. I've certainly had good leaders that expect this.
I particularly love when the “CTO” is also the main offender.
The thing with commit messages is that they are mostly never going to get a lot of scrutiny. But there are exceptions to this; especially if there are audits involved or external contributors. And of course when making a pull request to an OSS project, it is good form to make a bit of an effort. It depends on the context. I tend to focus more on diffs and pull requests. Not on the cryptic one liners that may or may not describe some of the changes. The right unit of change is a pull request, not individual commits.
And all this of course was when I was still able to keep on top of the massive volume of change. With AI that's simply no longer the case and the volume of change is only going to increase over time. Human reviews are now the main bottleneck to getting code merged. AIs probably should be doing a lot of the reviewing, gatekeeping testing, vetting, etc. Especially when AIs also produce most of the change. It's likely a lot of things will slip through unless you get your house in order on guard rails and process that your AI agents need to follow. As a CTO, guarding quality without becoming a human bottleneck is now the main challenge and removing bottlenecks responsibly is part of the job.
BTW. making AI tools write good commit messages is actually be a bit expensive. Many AI tools default to just summarizing the first message of a chat session under the assumption that just one thing changed over the course of a session. Making the AI look at the actual diff is of course possible and not that hard (just ask). And it definitely yields better descriptions when you do that. But it also takes more time and the token cost goes up as well. I'm not sure that's actually worth the expense in tokens. I tend to not bother with this. But again; depends on the context.
Earlier quoted context omitted.
> If someone uses git commits like the save function of their editor I use it like that too and yet the reviewers don't get to see these commits. Git has very powerful tools for manipulating the commit graph that many people just don't bother to learn. Imagine if I sent a patchset to the Linux Kernel Mailing List containing such "fix typo", "please work now", "wtf" patches - my shamelessness has its limits!
Seems like a lot of extra effort (save, add, commit, come up with some message even if it's a prayer to work now) only to undo it again later and create a patch or alternate history out of the final version. Why bother with the intermediate commits if you're not planning for it to be part of the history?
Plus, adding an extra point: When you run git log --oneline --graph and the pattern on the left is more complex than the Persian carpet patterns or Ancient Egyptian writings in the Great Pyramid of Giza, you know it's engineering & process quality issue than the code itself...
Earlier quoted context omitted.
Most often, what is happening is that people are groundlessly accusing others of writing AI slop.
This is 100% AI slop. It’s really not obvious to you? Look at the rest of this blog: https://piechowski.io/post/ Almost no posts since 2020, then a swarm of LLM-style clickbait titles… Oh wait, the 2020 one also has a clickbait title… and it was substantially rewritten in 2026!!
No need to read them, just a vibe check would be insightful. It's weird how branding, even before AI had a lot of the same catchy patterns, and now it's hard to define what is the right prose (engineers might want one thing and other role families others) and sometimes you're trying to write almost with the "everyone else bag in mind" because that's the personal connections you link your "here's what I often repeat in written form".
Earlier quoted context omitted.
Most often, what is happening is that people are groundlessly accusing others of writing AI slop.
This is 100% AI slop. It’s really not obvious to you? Look at the rest of this blog: https://piechowski.io/post/ Almost no posts since 2020, then a swarm of LLM-style clickbait titles… Oh wait, the 2020 one also has a clickbait title… and it was substantially rewritten in 2026!!
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…
Earlier quoted context omitted.
> At this point perhaps a million person-years have been sacrificed to the semantically incoherent shit UX of git. I have loathed git from the beginning but there's effectively no other choice. Yes! We mostly wouldn’t tolerate the complexity and the terrible UX of a tool we use everyday--but there's enough Stockholm Syndrome out there where most of us are willing to tolerate it.
Unless you're aware that such powerful commands are something you need once in a blue moon, and then you're grateful that the tool is flexible enough to allow them in the first place. Git may be sharp and unwieldy, but it's also one of the decreasing amount of tools we still use - the trend of turning tools into toys consumed the regular user market and is eating into tech software as well.
Git is NOT that.
Git is something you use to get stuff done, until it becomes an irritating obstacle course of incidental complexity.