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

331–340 of 546 posts

Re: Git commands I run before reading any code

#331

Post by gspr »

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.

You and me both. Git is just so prevalent and fundamental to so much these days that I forced myself to use only a cheat sheet lying on my desk until I could comfortably use a reasonably productive subset by memory. Little did I know that that would make my colleagues think I'm some sort of git sage.

But jq I use maybe once a week, and it just won't stick. Same for any git features beyond basic wrangling of the history tree (but, on the flip side, that basic wrangling has eliminated 99% of the times I have to look things up).

Re: Git commands I run before reading any code

#332

Post by tkzed49 »

ElijahLynn wrote: post #310
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…

And in a squash and merge workflow, which are most teams I've been on the past 8 years, it really is the title of the pull request or merge request. That is what really matters. And I really like that because it leaves room to let the developer do whatever kind of commit messages they want to that makes sense to them. Because nobody's really ever going to read those again after it squashed and merged.

Every time I hear about commit messages on HN, this is my first thought. I can't imagine not working in a squash workflow. No matter how good your commit messages are, I do not want to read all of them. The squashed commit will direct me to the original PR in case I need more detail.

Re: Git commands I run before reading any code

#333

Post by kevstev »

Aperocky wrote: post #213
joshstrange wrote: post #147

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…

Also - be careful of automated workflow that uses a single persons credential.. skews this by a lot.

Once word got out that a report was going up to a department head around commit frequency, a few of us started to make "backup commits" to boost our stats. Whether it be dev server config files (just in case!), local dev setups, whatever.. just something that changed enough on its own but would produce a steady stream of commits, while having some potential use case, however unlikely it was to actually be needed.

Modern problems require modern solutions and all...

Re: Git commands I run before reading any code

#334

Post by OkayPhysicist »

orsorna wrote: post #80
duskdozer wrote: post #45

Earlier quoted context omitted.

if you mean better messages, it's not really that. those junk messages should be rewritten and if the commits don't stand alone, merged together with rebase. it's the "logical chunks" the parent mentioned. it's hard to say fully, but unless a changeset is quite small or otherwise is basically 0% or 100%, there are usually smaller steps. like kind of contrived but say you have one function that uses a helper. if there…

If the code base is idempotent, I don't think showing commit history is helpful. It also makes rebases more complex than needed down the line. Thus I'd rather squash on merge. I've never considered how an engineer approaches a problem. As long as I can understand the fundamental change and it passes preflights/CI I don't care if it was scryed from a crystal ball. This does mean it is on the onus of the engineer to ex…

If you don't care about how the problem was solved, why are you reviewing it at all?

Re: Git commands I run before reading any code

#335

Post by mgfist »

awesome_dude wrote: post #330
mgfist wrote: post #89

Earlier quoted context omitted.

Same, but now with AI I don't have to remember that anymore

For now - the law of enshittification means that the free/cheap access to AI will be curtailed soon enough.

Pretty much any OS locally runnable LLM can generate this stuff.

Re: Git commands I run before reading any code

#336

Post by dcre »

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…

Saw all the replies crying over how verbose these are, clicked through to TFA expecting to see simpler commands. Nope, they're basically the same thing, just slightly shorter. I would never memorize either the jj or git versions if I planned to use them regularly; I'd make aliases.

Re: Git commands I run before reading any code

#337

Post by xyst »

might be useful if there’s an established commit message formatting. But for a majority of Fortune 500 to small businesses that I have worked for this is not the case. Usually you see shit like this:

On main:

2020-01-01: "Changes"

2020-01-05: "Changes"

2020-01-06: "merge "

2020-01-07: "revert "

Then there’s the people that include merge commits despite agreeing on rebasing.

Occasionally see sprinkles of decent, consistently formatted commit messages.

I think this is only useful on medium to large _open source_ projects. Clearly established CONTRIBUTING.md/README.md and commit formatting/merging guide.

Re: Git commands I run before reading any code

#338

Post by TeMPOraL »

alwillis wrote: post #283
crispyambulance wrote: post #129

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…

> 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. Yes! We mostly wouldn’t tolerate the complexity and the terrible UX of a tool we use everyday--but there's enough Stockholm Syndrome out there where most of us are willing to tolerate it.

Unless you're aware that such powerful commands are something you need once in a blue moon, and then you're grateful that the tool is flexible enough to allow them in the first place.

Git may be sharp and unwieldy, but it's also one of the decreasing amount of tools we still use - the trend of turning tools into toys consumed the regular user market and is eating into tech software as well.

Re: Git commands I run before reading any code

#339

Post by AStrangeMorrow »

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 also like meaningful commit names. But am sometimes guilty of “hope this works now” commits, but they always follow a first fix that it turns out didn’t cut it.

I work on a lot of 2D system, and the only way to debug is often to plot 1000s of results and visually check it behaves as expected. Sometimes I will fix an issue, look at the results, and it seems resolved (was present is say 100 cases) only to realize that actually there are still 5 cases where it is still present. Sure I could amend the last commit, but I actually keep it as a trace of “careful this first version mostly did the job but actually not quite”

Post reply on HN