Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Git commands I run before reading any code

piechowski.io

Post reply on HN
Print view View original

351–360 of 546 posts

Re: Git commands I run before reading any code

#351

Post by cratermoon »

agateau wrote: post #344
PUSH_AX wrote: post #246

Earlier 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? Personally no, the code is the "truth". If I need more I'm going to open a dialog with the author, not spend time trying to interpret a 7 word commit message, "good" or otherwise.

The code is the present truth, the commit messages can inform you about how it got turned into this truth. Interestingly, I recently wrote a short article about this: https://agateau.com/2026/on-commit-messages/

Your argument on conventional commits is something I've come to agree with. There are even tools that can generate release notes from conventional commits, and they are premised on the same mistake.

Re: Git commands I run before reading any code

#352

Post by cratermoon »

PUSH_AX wrote: post #300
mgfist wrote: post #297

Earlier quoted context omitted.

Which circles back to why it's important for leadership to tackle this

Yes, but not in the form of commit messages, the parent comment described things better suited to jira tickets, documentation etc. It feels like we're trying really hard to stretch the utility of commit messages here...

You'll at least need the discipline to include the ticket ID in the message. Links to documentation are ok, but they will likely rot and even if they don't the content may change such that it no longer accurately reflects the commit changes.

Re: Git commands I run before reading any code

#353

Post by fmbb »

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

Well isn't it typical that the person who wrote is also the person that merged? I have never worked in a place where that is not the norm for application code.

Even if you are one of those insane teams that do not squash merge because keeping everyone's spelling fixes and "try CI again" commits is important for some reason, you will still not see who _wrote_ the code, you will only see who committed the code. And if the person that wrote the code is not also the person that merges the code, I see no reason to trust that the person making commits is also the person writing the code.

Re: Git commands I run before reading any code

#354

Post by tcoff91 »

Exoristos wrote: post #291
mamcx wrote: post #273

Earlier quoted context omitted.

No, jj is super simple in daily use, in contrast with git that is a constant chore (and any sane person use alias). This include stuff that in git is a total mess of complexity like dealing with rebases. So not judge the tool for this odd case.

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.

Re: Git commands I run before reading any code

#355

Post by lamasery »

rjh29 wrote: post #347
deno wrote: post #322

Earlier quoted context omitted.

I mean let's not be hasty. Mechanical keyboards used to be just normal keyboards when computers were still computers.

That is a fair argument. I don't know why they dropped out of favour - price? Noise?

My guess would be price. Shoppers probably got more sensitive to the price of a keyboard as the price of computers dropped, and approximately none of them were choosing between two computer-bundles at the store with any regard for keyboard quality.

Re: Git commands I run before reading any code

#356

Post by bastardoperator »

rjh29 wrote: post #311
palata wrote: post #4

Earlier quoted context omitted.

To me, it makes jujutsu look like the Nix of VCSes. Not meaning to offend anyone: Nix is cool, but adds complexity. And as a disclaimer: I used jujutsu for a few months and went back to git. Mostly because git is wired in my fingers, and git is everywhere. Those examples of what jujutsu can do and not git sound nice, but in those few months I never remotely had a need for them, so it felt overkill for me.

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?

Looks like the Perl of Git too. Those commands are wild compared to vanilla git.

Re: Git commands I run before reading any code

#357

Post by juped »

l72 wrote: post #259
seba_dos1 wrote: post #28

Earlier quoted context omitted.

I don't think there's much nuance in the "I don't know --first-parent exists" workflow. Yes, you may sometimes squash-merge a contribution coming from someone who can't use git well when you realize that it will just be simpler for everyone to do that than to demand them to clean their stuff up, but that's pretty much the only time you actually have a good reason to do that.

I really, really wish git changed two defaults: * git merge ALWAYS does a merge and git pull ALWAYS does a fast forward. * git log --first-parent is the default. Have a git log --deep if you want to go down into branches. If you use a workflow that always merges a PR with a merge commit, then git log --first-parent gives you a very nice linear history. I feel like if this was the default, so many arguments about squa…

I agree.

I set merge.ff = false and alias ff to merge --ff-only. I don't use pull but I do have pull.ff = only set, just in case someday I do.

The graph log and the first-parent log serve different purposes and possibly shouldn't be the same command conceptually; this varies by user preference but the first-parent log is more of a "good default", generally. Merges do say "Merge" at the start, after all.

This is what I advise people to do in consulting engagements, too, it's not one of my personal quirks.

Re: Git commands I run before reading any code

#358

Post by asdfman123 »

ryandrake wrote: post #193
ramijames wrote: post #124

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.

Yes, and a culture problem, too. I guess I've been blessed that I've mostly only worked for "grown up" companies, but I've never encountered a workplace where people didn't write useful commit messages. At least one line description of the work done, but often multiple lines of valuable context. Only the junior devs had to be told to do it, but once they got into the habit, everyone understood why we do it and it was…

> I'd start to wonder what else the developers here do carelessly

More likely you'd already know by this point because it would be staring you in the face

Re: Git commands I run before reading any code

#359

Post by juped »

l72 wrote: post #262
skydhash wrote: post #103

Earlier quoted context omitted.

Do people actually share PR as in different people contributing to the same branch? Also I can understand not squashing if the contribution comes from outside the organization. But in that case, I would expect a cleaned up history. But if every contribution is from members of the team, who can merge their own PR, squash merge is an easy way to get a clean history. Especially when most PR should be a single commit.

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…

Somewhat Linux-like. You could probably improve it purely from a git perspective by letting subtask dependencies be many-to-many (the commit graph is a dependency graph), but what you have is probably best for your whole Jira workflow.
Post reply on HN