Made a claude skill! This is gold
Git commands I run before reading any code
481–490 of 546 posts
Re: Git commands I run before reading any code
#482Earlier quoted context omitted.
Good commit messages would be nice but honestly I would be over the moon if our pull requests would be approved within a week without having to ping one or more people.
Maybe you need to make shorter PRs?
haha as if. I mostly do bugfixes, small features, and otherwise most of my PRs are just unit text fixes so that our CI jobs run again (because my colleagues don't seem to care about breaking tests, so I get to fix everyone's tests, so that QA doesn't go postal).
To put it into numbers: my PRs are usually less than 5 files changed, and very little changes in those files.
Re: Git commands I run before reading any code
#483Earlier quoted context omitted.
Useless? So you never use “git annotate” or your IDE to see who wrote a line of code whose purpose puzzles you, and go to the commit message to see what they were trying to accomplish? This is invaluable to me as long as commit messages are clear. As a manager, one of the first things I do is make sure that the PR titles (the PR text becomes the commit messages in squash-merging workflows) at minimum begin with a tic…
> you never use “git annotate” or your IDE to see who wrote a line of code whose purpose puzzles you, and go to the commit message to see what they were trying to accomplish? This is invaluable to me as long as commit messages are clear. You're thinking like someone with a mature understanding of version control. Plenty of developers seem set on going their whole careers using git like beginners.
That sounds clever until you remember tools exist to solve actual problems.
Treating simple workflows as inferior is like saying a carpenter is amateurish for not using every attachment in the workshop. Some teams don't have enough upstream issues that they need to lean on git in the way you do maybe?
Re: Git commands I run before reading any code
#484> If the team squashes every PR into a single commit, this output reflects who merged, not who wrote. Squash-merge workflows are stupid (you lose information without gaining anything in return as it was easily filterable at retrieval anyway) and only useful as a workaround for people not knowing how to use git, but git stores the author and committer names separately, so it doesn't matter who merged, but rather wheth…
Squash merge is the only reasonable way to use GitHub: If you update a PR with review feedback, you shouldn’t change existing commits because GitHub’s tools for showing you what has changed since your last review assume you are pushing new commits. But then you don’t want those multiple commits addressing PR feedback to merge as they’re noise. So sure, there’s workflows with Git that doesn’t need squashing. But they’…
> But then you don’t want those multiple commits addressing PR feedback to merge as they’re noise.
They're not noise, they tell future maintainers why something is the way it is. If it's done in an unusual way they can see in the blame that a couple of lines were changed separately from the rest and immediately get an explanation by checking that commit.
Re: Git commands I run before reading any code
#485Earlier quoted context omitted.
I refuse to have alises and other custom commands. Either it is useful for everyone and so I make a change to the upstream project (I have never done this), or it won't exist next time I change my system so there is no point. I do have some custom tools that I am working on that haven't been released yet, but the long term goal is either delete them or release them to more people who will use them so I know it will b…
> I refuse to have alises and other custom commands. I am the same way, and have caught much flack for it over the years. But when I sit down at a foreign system (foreign in the sense that I haven't used it before) because something is broken and my help was requested, I don't have any need to lean on aliases. I worked with someone once that had a very impressive bashrc, and it was very effective for them... on their…
it's a tradeoff for sure. With dig especially I can't ever remember the normal syntax because I have aliases and scripts for things. I feel the aliases are wroth it since I'm on my own machine(s) 99.5% of the time, but it does suck to be handicapped
Re: Git commands I run before reading any code
#486[dead]
Re: Git commands I run before reading any code
#487This is a great list of commands to quickly understand a repository. Thank you for sharing.
Agreed.
Re: Git commands I run before reading any code
#488Earlier quoted context omitted.
Not really very similar at all for the scenario discussed here. Rerere remembers how you have resolved a conflict before. It doesn't let you rebase a stack of commits that result in different conflicts. You will have to stop and resolve each conflict and then `git rebase --continue`. However, the conflict algebra does remove many common uses of rerere. See https://github.com/jj-vcs/jj/issues/175#issuecomment-1079831.…
Avoiding manual conflict resolution isn't really a good thing though - conflicts are an indication that multiple different changes affect some code and you really should think hard about what the combination of them should be. Even what git does automatically already can be dangerous.
I agree, but that doesn't seem relevant. I did not say the jj automatically resolves conflicts.
Re: Git commands I run before reading any code
#489[dead]
Re: Git commands I run before reading any code
#490Earlier quoted context omitted.
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!!
I'd be curious to see if my blog posts/titles feel like AI slop to you. https://alexhans.github.io/ 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 e…
No, they don't, and I don't try to judge a book by its cover, anyway.
TBC, I don't dislike LLM-written articles because I think the author is being lazy, and I can even live with the LLM-isms. I dislike LLM-written articles in the main because they're lousy at serving their purpose of communicating some interesting human thought to other humans. They are very good at creating the illusion that's what's happening, hence all the upvotes.