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

11–20 of 546 posts

Re: Git commands I run before reading any code

#11

Post by theshrike79 »

seba_dos1 wrote: post #8

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

Can you explain to me (an avid squash-merger) what extra information do you gain by having commits that say "argh, let's see if this works", "crap, the CI is failing again, small fix to see if it works", "pushing before leaving for vacation" in the main git history?

With a squash merge one PR is one commit, simple, clean and easy to roll back or cherry-pick to another branch.

Re: Git commands I run before reading any code

#12

Post by filcuk »

seba_dos1 wrote: post #8

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

Having the tree easy to filter doesn't matter if it returns hundreds of commits you have to sift through for no reason.

Re: Git commands I run before reading any code

#13

Post by theshrike79 »

traceroute66 wrote: post #9

> The 20 most-changed files in the last year. The file at the top is almost always the one people warn me about. What a weird check and assumption. I mean, surely most of the "20 most-changed files" will be README and docs, plus language-specific lock-files etc. ? So if you're not accounting for those in your git/jj syntax you're going to end up with an awful lot of false-positive noise.

Why would you touch the README file hundreds of times a year?

You're right about package.json, pnpm-lock etc though, but those are easy to filter out if the project in question uses them.

Re: Git commands I run before reading any code

#14

Post by szszrk »

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?

Could be also that a frequently edited file had most opportunity to be broken. And it was edited by the most random crowd.

Re: Git commands I run before reading any code

#15

Post by arnorhs »

seba_dos1 wrote: post #8

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

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" :)

Re: Git commands I run before reading any code

#16

Post by nulltrace »

dewey wrote: post #7
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?

I've just tried this, and the most touched files are also the most irrelevant or boring files (auto generated, entry-point of the service etc.) in my tests.

Yeah same thing happens with lockfiles and CI configs. You end up filtering out half the list before it tells you anything useful.

Re: Git commands I run before reading any code

#17

Post by [deleted] »

dewey wrote: post #7
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?

I've just tried this, and the most touched files are also the most irrelevant or boring files (auto generated, entry-point of the service etc.) in my tests.

[deleted]

Re: Git commands I run before reading any code

#18

Post by seba_dos1 »

theshrike79 wrote: post #11
seba_dos1 wrote: post #8

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

Can you explain to me (an avid squash-merger) what extra information do you gain by having commits that say "argh, let's see if this works", "crap, the CI is failing again, small fix to see if it works", "pushing before leaving for vacation" in the main git history? With a squash merge one PR is one commit, simple, clean and easy to roll back or cherry-pick to another branch.

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.

Re: Git commands I run before reading any code

#19

Post by rbonvall »

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?

Just like that place that's so crowded nobody goes there anymore.

Re: Git commands I run before reading any code

#20

Post by mchaver »

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?

Definitely not in my experience. The most changed are the change logs, files with version numbers and readmes. I don't think anyone is afraid of keeping those up to date.
Post reply on HN