Git commands I run before reading any code • Hacker News Board

Re: Git commands I run before reading any code

#361

Post by skydhash » Wed, Apr 08, 2026, 8:44 PM UTC

alwillis wrote: post #283

crispyambulance wrote: post #129

Earlier quoted context omitted.

I am convinced that the vast majority of professionals simply don't bother to remember and, ESPECIALLY WITH GIT, just look stuff up every single time the workflow deviates from their daily usage. 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. That said, the OP's commands are…

> 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.

Why should there be tolerance? You look it up once, then write a script or an alias if it's part of your workflow. Or made a note if it's worth that. I use magit and I get quick action and contextual help at every step of my interaction with git.

Re: Git commands I run before reading any code

#362

Post by juped » Wed, Apr 08, 2026, 8:44 PM UTC

mcpherrinm wrote: post #271

l72 wrote: post #267

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.

No.

The cases where bisect fails you are, basically, ones where it lands on a merge that does too much - you now have to manually disentangle the side that did too much to find out exactly what interaction caused the regression. But this is on the rarer side because it's rare for an interaction to be what caused the regression, it's more common that it's a change - which will be in a non-merge commit.

The squash merge workflow means every single commit is a merge that does too much. Bisect can't find anything useful for you by bisection anymore, so you have to get lucky about how much the merge did, unenriched by any of the history that you deleted.

Re: Git commands I run before reading any code

#363

Post by hbn » Wed, Apr 08, 2026, 8:48 PM UTC

ramijames wrote: post #124

bsuvc wrote: post #90

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…

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.

One of the best developers I work with commits everything with the message "changes"

(This is not an endorsement to do that, he's a good developer in spite of his shitty commit messages)

Re: Git commands I run before reading any code

#364

Post by ball_of_lint » Wed, Apr 08, 2026, 8:54 PM UTC

giancarlostoro wrote: post #284

> One caveat: squash-merge workflows compress authorship. If the team squashes every PR into a single commit, this output reflects who merged, not who wrote. Worth asking about the merge strategy before drawing conclusions. I abhor squash merging for this and a few other reasons. I literally have to go out of my way to re-check out a branch. Someone who wants to use my current branch cannot do so if I merge my change…

You don't have to rewrite the source branch to squash merge?

I wouldn't describe it as "cleaning up the history". And the goal isn't to save space, it's to keep a linear history where things ought to be working at each commit (to enable tools like git bisect and similar).

I personally don't ensure everything is working every time I commit - That's what CI is for. The exact process I work through while writing a PR shouldn't impact other people's workflows, so when I merge back into a central branch it should really only reveal the granularity at which I assert 'this code is working and good', which is NOT every intermediate commit I make. Squash merge is a way to do that that fits nicely with existing engineering workflows, like code review.

Re: Git commands I run before reading any code

#365

Post by ngruhn » Wed, Apr 08, 2026, 8:55 PM UTC

crispyambulance wrote: post #129

stingraycharles wrote: post #85

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.

I am convinced that the vast majority of professionals simply don't bother to remember and, ESPECIALLY WITH GIT, just look stuff up every single time the workflow deviates from their daily usage. 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. That said, the OP's commands are…

I don't even think git cli UX is that bad. Didn't git pioneer this sub-command style? Much better than like e.g. ffmpeg. Sure some aspects are confusing. I still don't understand why `checkout` is both for changing branches and clearing uncommitted changes. But overall I think the tool is amazing. I've not observed a bug in git once.

Re: Git commands I run before reading any code

#366

Post by zhengyi13 » Wed, Apr 08, 2026, 8:58 PM UTC

FrankBooth wrote: post #329

SatvikBeri wrote: post #315

Earlier quoted context omitted.

It's totally compatible though, and that's a big selling point. I use jj and nobody else at my work uses it and that has never been an issue.

It doesn’t support submodules. So no, not totally compatible.

That's a feature, not a bug /s

Re: Git commands I run before reading any code

#367

Post by agumonkey » Wed, Apr 08, 2026, 9:01 PM UTC

ramon156 wrote: post #5

> The 20 most-changed files in the last year. The file at the top is almost always the one people warn me about. “Oh yeah, that file. Everyone’s afraid to touch it.” The most changed file is the one people are afraid of touching?

Maybe it's a start to find conflict-prone regions ?

otherwise you're right, it could be a long linear list of appends where people are happy to contribute.

Re: Git commands I run before reading any code

#368

Post by alt_422568 » Wed, Apr 08, 2026, 9:06 PM UTC

xp84 wrote: post #242

PUSH_AX wrote: post #164

Earlier quoted context omitted.

I think it's a stretch to measure leadership quality on something so minor, a lot of teams find them pretty useless no matter how good they are.

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.

Re: Git commands I run before reading any code

#369

Post by beanjuiceII » Wed, Apr 08, 2026, 9:09 PM UTC

tcoff91 wrote: post #354

Exoristos wrote: post #291

Earlier quoted context omitted.

One rarely needs more from git than `git add -A && git commit -m`.

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?

Re: Git commands I run before reading any code

#370

Post by twoodfin » Wed, Apr 08, 2026, 9:10 PM UTC

gpvos wrote: post #306

avazhi wrote: post #211

More AI slop. Wtf is happening to this website

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!!