Live data from Hacker News

Git commands I run before reading any code

piechowski.io

51–60 of 546 posts

Re: Git commands I run before reading any code

#51
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 can't remember all of this, does anyone know of any LLM model trained on CLI which can be run locally?

Re: Git commands I run before reading any code

#52

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

You gain the extra information by having reasonable commit messages rather than the ones you mentioned. To fix CI you force push.

Can you explain to me what an avid squash-merger puts into the commit message of the squashed commit composed of commits "argh, let's see if this works", "crap, the CI is failing again, small fix to see if it works", and "pushing before leaving for vacation" ?

Re: Git commands I run before reading any code

#53
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?

This command needs a warning. Using this command and drawing too many conclusions from it, especially if you’re new, will make you look stupid in front of your team mates.

I ran this on the repo I have open and after I filtered out the non code files it really can only tell me which features we worked on in the last year. It says more about how we decided to split up the features into increments than anything to do with bugs and “churn”.

Re: Git commands I run before reading any code

#54

I have a summary alias that kind of does similar things # summary: print a helpful summary of some typical metrics summary = "!f() { \ printf \"Summary of this branch...\n\"; \ printf \"%s\n\" $(git rev-parse --abbrev-ref HEAD); \ printf \"%s first commit timestamp\n\" $(git log --date-order --format=%cI | tail -1); \ printf \"%s latest commit timestamp\n\" $(git log -1 --date-order --format=%cI); \ printf \"%d commi…

Looks nice. Unfortunately I don't have log-of-count-and-email, log-of-count-and-day or churn

Re: Git commands I run before reading any code

#55
post #54

I have a summary alias that kind of does similar things # summary: print a helpful summary of some typical metrics summary = "!f() { \ printf \"Summary of this branch...\n\"; \ printf \"%s\n\" $(git rev-parse --abbrev-ref HEAD); \ printf \"%s first commit timestamp\n\" $(git log --date-order --format=%cI | tail -1); \ printf \"%s latest commit timestamp\n\" $(git log -1 --date-order --format=%cI); \ printf \"%d commi…

Looks nice. Unfortunately I don't have log-of-count-and-email, log-of-count-and-day or churn

+1 Same.

Edit. https://github.com/mattrighetti/dotfiles/blob/master/.gitcon...

Re: Git commands I run before reading any code

#56

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

It’s easy enough to filter those out with grep. It still is relatively meaningless. If the team incrementally adds things then it’s just going to show what additions were made. It isn’t churn at all.

Re: Git commands I run before reading any code

#57
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 can't remember all of this, does anyone know of any LLM model trained on CLI which can be run locally?

If you copy those commands into a file and use that file to prompt the “sh” LLM.

Re: Git commands I run before reading any code

#59
post #40
post #29

Earlier quoted context omitted.

What if the shared place is the place where you run a bunch of CI? Then you push your work early to a branch to see the results, fix them etc.

You can always force-push a cleaned up version of your branch when you are ready for review, or start a new one and delete the WIP one.

I hate (and fear) force-pushing and "cleaning up" git history as much as other people dislike squash-merging =)

It just feels wrong to force push, destroying stuff that used to be there.

And I don't have the time or energy to bisect through my shitty PR commits and combine them into something clean looking - I can just squash instead.

Re: Git commands I run before reading any code

#60
post #15

Earlier quoted context omitted.

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

I think the point is that if you have to squash, the PR-maker was already gitting wrong. They should have "squashed" on their end to one or more smaller, logically coherent commits, and then submitted that result.

It’s not “having to squash”. The intent was already for a PR to be a single commit. I could squash it on my end and merge by rebasing, but any alteration would then need to be force-pushed. So I don’t bother. I squash-merge when it’s ready and delete the branch.
Post reply on HN