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

101–110 of 546 posts

Re: Git commands I run before reading any code

#101

Post by seba_dos1 »

theshrike79 wrote: post #69
seba_dos1 wrote: post #38

Earlier quoted context omitted.

I have no troubles working on big FLOSS projects where reviews usually happen at the commit level :)

So if a PR consists of 20 commits, they review every single commit linearly without looking at the end result first?

Yes, and in some projects 20 commits is not even a big PR, more like "regular sized". The LKML's first page is now full of PRs with around 20 commits, here's a random one as an example: https://lore.kernel.org/netdev/20260408121252.2249051-1-dhow...

And here's a slightly smaller one which isn't about "miscellaneous fixes": https://lore.kernel.org/netdev/20260408122027.80303-1-xuanzh...

Some of these commits even get reviewed by different maintainers before being merged, which is common when a patchset touches several subsystems at once.

Re: Git commands I run before reading any code

#102

Post by sigmoid10 »

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…

Only two of the five insights are based on commit messages and the author acknowledges that they won't work in projects without message discipline. But the remaining ones will give you valuable insights even into the most lazy project department.

Re: Git commands I run before reading any code

#103

Post by skydhash »

seba_dos1 wrote: post #28
arnorhs wrote: post #15

Earlier quoted context omitted.

The author is talking about the case where you have coherent commits, probably from multiple PRs/merges, that get merged into a main branch as a single commit. Yeah, I can imagine it being annoying that sqashing in that case wipes the author attribution, when not everybody is doing PRs against the main branch. However, calling all squash-merge workflows "stupid" without any nuance.. well that's "stupid" :)

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.

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.

Re: Git commands I run before reading any code

#104

Post by ipsento606 »

theshrike79 wrote: post #65
seba_dos1 wrote: post #18

Earlier quoted context omitted.

These commits reaching the reviewer are a sign of either not knowing how to use git or not respecting their time. You clean things up and split into logical chunks when you get ready to push into a shared place.

Why would the reviewer look at the commit messages instead of the code? 1. Open PR page in whatever tool you're using 2. Read title + description to see what's up 3. Swap to diff and start reading through the changes 4. Comment and/or approve I've never heard anyone bothering to read the previous commit messages for a second, why would they care?

>Swap to diff and start reading through the changes

this forces the reviewer to view the entire diff at once, which can greatly increase the cognitive load vs. being able to view diffs of logical units of work

for tiny PRs it may not matter, but for substantial PRs it can matter a lot

Re: Git commands I run before reading any code

#105

Post by Cthulhu_ »

For "what changes the most", in my project it's package.json / lock (because of automatic dependency updates) and translation / localization files; I'd argue that's pretty normal and healthy.

For the "bus factor", there's one guy and then there's me, but I stopped being a primary contributor to this project nearly two years ago, lol.

Re: Git commands I run before reading any code

#106

Post by itmitica »

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…

I love how the commentator thinks a developer makes decisions based on commit messages.

Random, subjective, or written in a state of mental exhaustion commit messages.

I also love the switcheroo the author made: git not logs. But hey :)

Re: Git commands I run before reading any code

#107

Post by Cthulhu_ »

stingraycharles wrote: post #85
pzmarzly wrote: post #3

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…

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 don't, I will google things and fiddle, then put it in a git alias (with a comment on what it does and / or where I got it from) and push it to my private dotfiles repo, taking it with me between computers and projects.

Re: Git commands I run before reading any code

#108

Post by Anon1096 »

seba_dos1 wrote: post #87
theshrike79 wrote: post #65

Earlier quoted context omitted.

Why would the reviewer look at the commit messages instead of the code? 1. Open PR page in whatever tool you're using 2. Read title + description to see what's up 3. Swap to diff and start reading through the changes 4. Comment and/or approve I've never heard anyone bothering to read the previous commit messages for a second, why would they care?

Because it's a useful abstraction. If you only look at PRs and don't ever care about commits, why are they even being sent to reviewer in the first place? Just send a diff file. Having atomic commits lets you actually benefit from having them. Suddenly you don't have to perform weird dances with interconnected PRs with dependencies as "PR too big" is not such a problem anymore as long as commits are digestible; you c…

> If you only look at PRs and don't ever care about commits, why are they even being sent to reviewer in the first place? Just send a diff file.

This is in fact what hg does with amending changesets and yes it works far better. Keep PRs small and atomic and you never need to worry about what happens intra-pr. If you need bigger units of work that's what stacking is for.

Re: Git commands I run before reading any code

#109

Post by huflungdung »

pzmarzly wrote: post #3

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…

[dead]

Re: Git commands I run before reading any code

#110

Post by Cthulhu_ »

duskdozer wrote: post #37
mattrighetti wrote: post #32

I have a summary alias that kind of does similar things # summary: print a helpful summary of some typical metrics summary = "!f() { \ printf \"Summary of this branch...\n\"; \ printf \"%s\n\" $(git rev-parse --abbrev-ref HEAD); \ printf \"%s first commit timestamp\n\" $(git log --date-order --format=%cI | tail -1); \ printf \"%s latest commit timestamp\n\" $(git log -1 --date-order --format=%cI); \ printf \"%d commi…

Curious - why write it as a function in presumably .gitconfig and not just a git-summary script in your path? Just seems like a lot of extra escapes and quotes and stuff

Not the poster, but one theory: so you only need to copy one file. Portability.
Post reply on HN