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

451–460 of 546 posts

Re: Git commands I run before reading any code

#451

Post by rightofcourse »

bob1029 wrote: post #148
mikepurvis wrote: post #118

Earlier quoted context omitted.

In codebases where PRs are squashed on merge, the commit messages on the main branch end up being the PR body description text, and that's actually reviewed so tends to be much better I find.

And in every codebase I've been in charge of, each PR has one or more issue # linked which describe every possible antagonizing detail behind that work. I understand this isn't inline with traditional git scm, but it's a very powerful workflow if you are OK with some hybridization.

It works until you migrate to a new system. In 5 years we are on our 3rd. I saw that at FAANG and startup alike. Then someone might dump the contents in JSON or just PDF for archival but much easier to have the commit msg have the relevant info - only relevant, losts of small details can be still on the issue and if someone really needs them can search those archives.

Re: Git commands I run before reading any code

#452

Post by account42 »

shiroiuma wrote: post #435
deno wrote: post #405

Earlier quoted context omitted.

Most people and companies just use the keyboard that shipped with the computer. I don't think noise is as much of an issue as people make it out be. Marketing made up this story about linear switches being for gamers. So now every mechanical keyboard needs to make unnecessary noise and offer extra resistance for harder bottom out or you're not a serious typist. But that's not inherent to the keyboard. Linear switches…

I'm not a gamer these days, but from what I've seen, the gamers like a different type of keyswitch than regular typists. Normal typists like a clicky keyswitch where it clicks with very little travel, and has plenty of travel after this to avoid bottoming out. (so, Cherry blue) Gamers want mechanical keyswitches with no click at all. (Cherry brown I think)

Cherry browns are more like an average mechanical switch (and not in a bad way - they're a good middle ground if you use your keyboard for different things). Gaming oriented keyboards would use different ones.

Re: Git commands I run before reading any code

#453

Post by account42 »

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 prefer `git commit --patch` and having a full editor for commit messages rather than a command-line -m argument to encourage me to actually write something useful.

Re: Git commands I run before reading any code

#454

Post by account42 »

martinvonz wrote: post #432
waisbrot wrote: post #406

Earlier quoted context omitted.

That sounds like https://git-scm.com/book/en/v2/Git-Tools-Rerere ?

Not really very similar at all for the scenario discussed here. Rerere remembers how you have resolved a conflict before. It doesn't let you rebase a stack of commits that result in different conflicts. You will have to stop and resolve each conflict and then `git rebase --continue`. However, the conflict algebra does remove many common uses of rerere. See https://github.com/jj-vcs/jj/issues/175#issuecomment-1079831.…

Avoiding manual conflict resolution isn't really a good thing though - conflicts are an indication that multiple different changes affect some code and you really should think hard about what the combination of them should be. Even what git does automatically already can be dangerous.

Re: Git commands I run before reading any code

#455

Post by account42 »

ygouzerh wrote: post #419
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.

It can be even enforced using hooks/pipelines that will check that the message follow Conventional Commits as well

> Conventional Commits

I though we were talking about good commit messages.

Re: Git commands I run before reading any code

#456

Post by alper »

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?

Pretty much everybody who does work at the real office where I am has a mechanical keyboard by now.

Re: Git commands I run before reading any code

#457

Post by alper »

palata wrote: post #4
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…

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.

Nix does not really work in that even basic things are absurdly complicated and can take days of messing with poor libraries and documentation.

That's not been my experience with jj which after the initial hurdle is a breeze.

Re: Git commands I run before reading any code

#458

Post by alper »

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…

> developers write commit messages

The people who don't write commit messages for us are the non developers.

Writing commit messages shouldn't take any time at all. If it does, then you probably have a range of other professional issues.

Re: Git commands I run before reading any code

#459

Post by [deleted] »

PUSH_AX wrote: post #246
xp84 wrote: post #242

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

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

[deleted]

Re: Git commands I run before reading any code

#460

Post by account42 »

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

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?
Post reply on HN