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

251–260 of 546 posts

Re: Git commands I run before reading any code

#251

Post by dzaima »

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.

jj's template and revset languages are very simple syntactically, so once you're comfortable with the few things you do use often it's just a question of learning about the other existing functions (even if only enough to know to look them up), which slot right in and compose well with everything else you know (unlike flags which typically have each their own system).

Or, perhaps better yet, defining your own functions/helpers as you go for things you might care about, which, by virtue of having been named you, are much easier to remember (and still compose nicely).

Re: Git commands I run before reading any code

#252

Post by berkes »

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?

Plotting Churn against Complexity is far more useful than merely churn.

It shows places that are problematic much better. High churn, low complexity: fine. Its recognized and optimizef that this is worked on a lot (e.g. some mapping file, a dsl, business rules etc). Low churn high complexity: fine too. Its a mess, but no-one has to be there. But both? Thats probably where most bugs originate, where PRs block, where test coverage is poor and where everyone knows time is needed to refactor.

In fact, quite often I found that a teams' call "to rewrite the app from scratch" was really about those few high-churn-high-complexity modules, files or classes.

Complexity is a deep topic, but even simple checks like how nested smt is, or how many statements can do.

Re: Git commands I run before reading any code

#253

Post by macintux »

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.

The code can only convey what is being done (and then, in some cases, only superficially). It can't convey what decisions were made, what alternatives were discarded, what business motivations may have led to that code.

And for old enough code, the author may not be available, or more likely doesn't remember.

Re: Git commands I run before reading any code

#254

Post by jlarocco »

I'm so used to magit, it seems kind of primitive to pipe git output around like this.

Anyway, I can glean a lot of this information in a few minutes scrolling through and filtering the log in magit, and it doesn't require memorizing a bunch of command line arguments.

Re: Git commands I run before reading any code

#255

Post by mikepurvis »

bikelang wrote: post #240
bob1029 wrote: post #148

Earlier quoted context omitted.

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.

I personally find this to be a substantially better pattern. That squashed commit also becomes the entire changeset - so from a code archeology perspective it becomes much easier to understand what and why. Especially if you have a team culture that values specific PRs that don’t include unrelated changes. I also find it thoroughly helpful to be able to see the PR discussions since the link is in the commit message.

I agree, much as it's a loss for git as a distributed system (though I think that ship sailed long ago regardless). As far as unrelated changes, I've been finding that another good LLM use-case. Like hey Claude pull this PR and break it up into three new branches that individually incorporate changes A, B, and C, and will cleanly merge in that order.

One minor nuisance that can come up with GitHub in particular when using a short reference like #123 is that that link breaks if the repo is forked or merged into something else. For that reason, I try to give full-url references at least when I'm manually inserting them, and I wish GitHub would do the same. Or perhaps add some hidden metadata to the merge commit saying "hey btw that #123 refers to https://github.com/fancy-org/omg-project/issues/123>"

Re: Git commands I run before reading any code

#256

Post by PUSH_AX »

macintux wrote: post #253
PUSH_AX wrote: post #246

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

The code can only convey what is being done (and then, in some cases, only superficially). It can't convey what decisions were made, what alternatives were discarded, what business motivations may have led to that code. And for old enough code, the author may not be available, or more likely doesn't remember.

Fine, but none of that is in a normal commit message, lets be real...

Re: Git commands I run before reading any code

#257

Post by dgb23 »

md224 wrote: post #236

The last sentence of the article is "Here’s what the rest of the week looks like." and then it just stops. Am I missing something?

It’s phrased in a confusing way, seems to be a mistake. It becomes clearer when you click the link in the sentence before.

Re: Git commands I run before reading any code

#258

Post by loremium »

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…

tbh I'm not convinced that a git log history should be treated as a group journal because it's not.

relying on git commit messages assumes they're correct by convention since there is no technical constraint to enforce it. and it assumes no work in progress commits, sometimes it's just necessary to hit the save button real quick or move a workspace from one device to another.

my point is: git is a way of storing and loading files at its core.

Re: Git commands I run before reading any code

#259

Post by l72 »

seba_dos1 wrote: post #28
arnorhs wrote: 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 don't think there's much nuance in the "I don't know --first-parent exists" workflow. Yes, you may sometimes squash-merge a contribution coming from someone who can't use git well when you realize that it will just be simpler for everyone to do that than to demand them to clean their stuff up, but that's pretty much the only time you actually have a good reason to do that.

I really, really wish git changed two defaults:

  * git merge ALWAYS does a merge and git pull ALWAYS does a fast forward.
  * git log --first-parent is the default. Have a git log --deep if you want to go down into branches.
If you use a workflow that always merges a PR with a merge commit, then git log --first-parent gives you a very nice linear history. I feel like if this was the default, so many arguments about squashing or rebasing workflows wouldn't be necessary to get our "linear history", everyone would just be doing merges and be happy with it. You get a clean top level history and you can dig down into the individual commits in a merge if you are bisecting for a bug.

Re: Git commands I run before reading any code

#260

Post by saila »

socalgal2 wrote: post #196
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…

a project isn’t dying because of no commits. Rather it’s stable I often feel I need to setup bots to make superfluous commits just to make it look like my useful and stable repos are “active” One example (not mine) a a qr-code generator library. Hasn’t been updated in 10 years. It’s perfect as is. It just provides the size and the bits. You convert those bits to any representation you want. It has no need to be updat…

This might be true for libraries or utilities that have a well-defined scope and no dependencies, but that's not what the article is focused on. When considering a company's main product, it's usually never done and patterns of activity—and especially changes in those patterns—can give you insight into potential issues.
Post reply on HN