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

531–540 of 546 posts

Re: Git commands I run before reading any code

#531

Post by ngruhn »

jcynix wrote: post #384
ngruhn wrote: post #365

Earlier quoted context omitted.

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.

> Didn't git pioneer this sub-command style? No, various other tools used it before git, e.g. openssl.

sure but it certainly popularized it

Re: Git commands I run before reading any code

#532

Post by xp84 »

PUSH_AX wrote: post #461
account42 wrote: post #460

Earlier quoted context omitted.

So rather than commit messages that stay in the repo you want the information in a place where its lost by the next buck tracker migration?

Look, I'll make this easy to understand. The parent comment that this stems from said: > It can't convey what decisions were made, what alternatives were discarded, what business motivations may have led to that code. If you're advocating this should all go in commit messages then I don't know what to say that I haven't already, it objectively doesn't belong there. The end.

I think we’re advocating for is that it contains a sufficient amount of context. Ideally it’s like “XYZ-123: Enable multi-foo support for Bar”

Links to ticket IDs are good, and good leaders don’t let old ticket links break on bugtracker migration.

A sentence or so to let future devs know what this change meant to do or at least what initiative it was intended to support, is also good. If future devs (even future YOU) don’t know what you were trying to do, they might revert a change which, without context, looks like a mistake.

Doing both ticket link + text is ideal because someone might screw up the ticket system, and a sentence on its own can be ambiguous.

Doing neither, on purpose, is just willful stupidity. Don’t even bother with Git if you want your commits, the ones that end up in “dev” I mean, to all just say “wip,” “asdf,” and “hope it works now.”

Re: Git commands I run before reading any code

#533

Post by xp84 »

hluska wrote: post #383
mgfist wrote: post #309

Earlier quoted context omitted.

Sure but code can't capture everything. Maybe with enough comments I guess, but not code alone. For example, code won't tell you that this feature was timeboxed hence this edgecase was not supported

And a commit message would convey that?

Having dumb or nonexistent commitment messages has 0% chance of communicating anything. If someone has at least made an effort, a future someone will be able to identify some of the following:

1. What project in general the change was associated with (it may not be obvious from the files changed in this single commit) which can indeed tell you how well it was spec’d- maybe you’ll even find the technical plan.

2. Possibly a hint of how the author intended it to work, or a clue about their misunderstanding. For example, the commit may have changed a function to accept a null argument to “solve” some other problem, but now you know that null passing through here is harmful, well thanks to the commit info, you know that you have to account for the problem that dev was “solving” if you don’t allow the null here. Without that you’d just revert the change and cause the other bug to regress.

Re: Git commands I run before reading any code

#534

Post by mosselman »

traceroute66 wrote: post #22
theshrike79 wrote: post #13

Earlier quoted context omitted.

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.

> Why would you touch the README file hundreds of times a year? You're right, perhaps I should have said CHANGELOG etc. Although some projects e.g. bump version numbers in README or add extra one-liner examples ....

Just look at the second file in the list then I guess.

This post is about exploring code, not documentation. Nobody is going to warn you about the README unless it is super outdated.

Re: Git commands I run before reading any code

#536

Post by gpvos »

twoodfin wrote: post #490
alexhans wrote: post #377

Earlier quoted context omitted.

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

Wow, what an air of superiority.

Re: Git commands I run before reading any code

#537

Post by a96 »

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?

That's the one that always broke something down the line leading to a stream of reverts and retries?

Re: Git commands I run before reading any code

#538

Post by mrunkel »

fmbb wrote: post #353

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

Code merges are made by reviewers in my org, not by the author.

Spend time educating your team about `git commit --amend` and `git push --force` on their own branches and you don't have to see any of that ugliness.

Re: Git commands I run before reading any code

#539

Post by mixmastamyk »

berkes wrote: post #519
vntok wrote: post #261

Earlier quoted context omitted.

This reads like the intern was left to his own devices and his output not checked at all for three weeks straight. Actual tutoring would have surfaced the issue after 1 or 2 days tops.

Oh, but I had a daily sit down and addressed this and other issues several times. The problem was, as I mentioned, "he though he was the best developer ever". stubborn as hell. And pushed back against anything he wasn't used to, anything that wasn't his usual "ssh or ftp into prod and change stuff until it works" because he thought this was the only method that worked. This was my first encounter with a self-proclaim…

Dismissed.

Re: Git commands I run before reading any code

#540

Post by twoodfin »

gpvos wrote: post #536
twoodfin wrote: post #490

Earlier quoted context omitted.

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

Wow, what an air of superiority.

Yes, my opinion is that the average highly upvoted deep dive technical article on HN was substantially better in 2023 than in 2026.

I also believe that the bulk of that degrade is due to frontier LLM’s currently being poorly trained to write such articles well, given whatever scale & sophistication of prompts the typical author is using.

Not to say they won’t be better someday (soon?)

Post reply on HN