Live data from Hacker News

Git commands I run before reading any code

piechowski.io

421–430 of 546 posts

Re: Git commands I run before reading any code

#421

I ran these commands on a number of codebases I work on and I have to say they paint a very different picture than the reality I know to be true. > git shortlog -sn --no-merges Is the most egregious. In one codebase there is a developer's name at the top of the list who outpaced the number 2 by almost 3x the number of commits. That developer no longer works at the company? Crisis? Nope, the opposite. The developer wa…

Same. Someone we brought on that worked for about a month and vibe coded to hell caused a lot of damage in terms of tech debt and that list shows. Looks like he managed 124 commits in a single week. The same repo, our top dev only has around 500 in its entirety.

Also important to have a plan for code review and merges when a lead is out of town. I found out I needed to reevaluate how that's handed when I was gone for two weeks.

Re: Git commands I run before reading any code

#422
post #393

I ran these commands on a number of codebases I work on and I have to say they paint a very different picture than the reality I know to be true. > git shortlog -sn --no-merges Is the most egregious. In one codebase there is a developer's name at the top of the list who outpaced the number 2 by almost 3x the number of commits. That developer no longer works at the company? Crisis? Nope, the opposite. The developer wa…

I suspect OP never actually ran these commands and this article was brainstormed and written by an LLM.

There's some giveaways that it was too. "It's not x, its y."

Re: Git commands I run before reading any code

#423

Trusting the messages to contain specific keywords seems optimistic. I don't think I used "emergency" or "hotfix" ever. "Revert" is some times automatically created by some tools (E.g. un-merging a PR).

We use branch names like `hotfix/some-hotfix-name`, don't think I've seen many commits mention hotfix directly.

Re: Git commands I run before reading any code

#424

Earlier quoted context omitted.

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…

Good commit messages would be nice but honestly I would be over the moon if our pull requests would be approved within a week without having to ping one or more people.

Maybe you need to make shorter PRs?

Re: Git commands I run before reading any code

#425
post #365

Earlier quoted context omitted.

I am convinced that the vast majority of professionals simply don't bother to remember and, ESPECIALLY WITH GIT, just look stuff up every single time the workflow deviates from their daily usage. At this point perhaps a million person-years have been sacrificed to the semantically incoherent shit UX of git. I have loathed git from the beginning but there's effectively no other choice. That said, the OP's commands are…

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.

> I still don't understand why `checkout` is both for changing branches and clearing uncommitted changes.

Because `checkout` is for getting the working directory to the state of a specific revision. Which both means switching branches (which are just pointer to revisions) and clearing changes (and get back to the starting revision). In both cases, you "check out" the version of the file at a specific commit or HEAD.

Re: Git commands I run before reading any code

#426
post #405
post #347

Earlier quoted context omitted.

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

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 find the resistance to be a hindrance when typing. Fastest typing speed and comfort for me is my thinkpad keyboard which uses scissor switches with a very low profile - you need less effort per keystroke!

Re: Git commands I run before reading any code

#427
post #363

Earlier quoted context omitted.

One of the best developers I work with commits everything with the message "changes" (This is not an endorsement to do that, he's a good developer in spite of his shitty commit messages)

Obviously a very unpopular opinion, but I guess for my own sake it's hard to write commit messages, because for me it's that I have never really even found use of other people commit messages, and I rarely even attempt to. Ultimately code is code and I don't care about how it got to how it is. I got same issue with documentation and comments or really anything that isn't building stuff. I don't like writing it, don't…

Yeah I also don't really write commit messages. If your pull request becomes associated with that commit, and the history gets squashed, then that one commit becomes a link to the pull request where all the necessary info is. I just write "commit" for all my messages.

Re: Git commands I run before reading any code

#428
post #81

Earlier quoted context omitted.

Hah someone really looked at jq (?) and thought: "yes, more of this everywhere". I feel jq is like marmite (edit: aka vegemite, i.e. "you either love it or you hate it")

It doesn't seem any more egregious than something like: `git log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue) %Creset' --abbrev-commit --` Which is something I see a lot of people alias in Git for viewing logs.

> `git log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)%Creset' --abbrev-commit --`

If you remove the rainbow specification, it should be

  git log --graph --pretty=format:'%h -%d %s (%cr) ' --abbrev-commit --
And most programmers are used to C style formatting.

Re: Git commands I run before reading any code

#429
post #393

Earlier quoted context omitted.

I suspect OP never actually ran these commands and this article was brainstormed and written by an LLM.

There's some giveaways that it was too. "It's not x, its y."

I'm getting a mixed reading, the most egregious flags aren't present, but there are a couple.

As you identified there is a lot of parallel sentence structure.

They also have a bunch of lists of 3-5 items which is a classic.

It doesn't have the anodyne rambling never getting to the point style common to LLMs

Re: Git commands I run before reading any code

#430
post #427

Earlier quoted context omitted.

Obviously a very unpopular opinion, but I guess for my own sake it's hard to write commit messages, because for me it's that I have never really even found use of other people commit messages, and I rarely even attempt to. Ultimately code is code and I don't care about how it got to how it is. I got same issue with documentation and comments or really anything that isn't building stuff. I don't like writing it, don't…

Yeah I also don't really write commit messages. If your pull request becomes associated with that commit, and the history gets squashed, then that one commit becomes a link to the pull request where all the necessary info is. I just write "commit" for all my messages.

On my local copy of the repo, commits are notes to myself. I don't use the `--message` switch. I let git bring up my $EDITOR where I type what I did since the last commit. This helps when I'm writing the PR description and when I'm rebasing the branch on top of the main trunk. And then some time, I need to do a bit of git-fu and split the changes into different PRs. Hard to do this with generic messages.

But I use magit and I can commit specific lines and hunks as easily as files. That helps with managing changes to meaningfully group them.

Post reply on HN