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

111–120 of 546 posts

Re: Git commands I run before reading any code

#111

Post by Zambyte »

arccy wrote: post #66
palata wrote: post #39

Earlier quoted context omitted.

Actually, signing was one of the annoying parts of jujutsu for me: I sign with a security key, and the way jujutsu handled signing was very painful to me (I know it can be configured and I tried a few different ways, but it felt inherent to how jujutsu handles commits (revisions?)).

The only reasonable way to use signing in jj is with the sign-on-push config https://docs.jj-vcs.dev/latest/config/#automatically-signing... rather than as commits are made

Why? I have my signing behavior set to own and I haven't noticed any issues, but I don't actually rely on signatures for much.

Re: Git commands I run before reading any code

#112

Post by Cthulhu_ »

pydry wrote: post #84
dewey wrote: post #7

Earlier quoted context omitted.

I've just tried this, and the most touched files are also the most irrelevant or boring files (auto generated, entry-point of the service etc.) in my tests.

I just tried it too and it basically just flagged a handful of 1500+ line files which probably ought to be broken up eventually but arent causing any serious problems.

If it's (like in my case) dependency management, localization or config files, breaking them up will likely only cause more issues. Make sure that it's an actual improvement before breaking things up.

Re: Git commands I run before reading any code

#113

Post by pscanf »

I just finished¹ building an experimental tool that tries to figure out if a repo is slopware or not just by looking at it's git history (plus some GitHub activity data).

The takeaway from my experiment is that you can really tell a lot by how / when / what people commit, but conclusions are very hard to generalize.

For example, I've also stumbled upon the "merge vs squash" issue, where squashes compress and mostly hide big chunks of history, so drawing conclusions from a squashed commit is basically just wild guessing.

(The author of course has also flagged this. But I just wanted to add my voice: yeah, careful to generalize.)

¹ Nothing is ever finished.

Re: Git commands I run before reading any code

#114

Post by seba_dos1 »

mgfist wrote: post #100
tasuki wrote: post #49

Earlier quoted context omitted.

> A good reviewer looks at the end-state and does not care about individual commits. Then I must be a bad reviewer. In a past job, I had a colleague who meticulously crafted his commits - his PRs were a joy to review because I could go commit by commit in logical chunks, rather than wading through a single 3k line diff. I tried to do the same for him and hope I succeeded.

Why are those not just separate PRs? Or if they really needed to be merged at once - they should still be separate PRs but on a feature branch

Why have PRs - groups of commits to pull - then if all you need is a single patch file?

Re: Git commands I run before reading any code

#115

Post by mgfist »

mcpherrinm wrote: post #64
seba_dos1 wrote: post #8

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

Squash merge is the only reasonable way to use GitHub: If you update a PR with review feedback, you shouldn’t change existing commits because GitHub’s tools for showing you what has changed since your last review assume you are pushing new commits. But then you don’t want those multiple commits addressing PR feedback to merge as they’re noise. So sure, there’s workflows with Git that doesn’t need squashing. But they’…

Yes, I think people who are anti squash merge are those who don't work in Github and use a patch based system or something different. If you're sending a patch for linux, yes it makes sense that you want to send one complete, well described patch. But Github's tooling is based around the squash merge. It works well and I don't know anyone in real life who has issues with it.

And to counter some specific points:

* In a github PR, you write the main commit msg and description once per PR, then you tack on as many commits as you want, and everyone knows they're all just pieces of work towards the main goal of the eventually squashed commit

* Forcing a clean up every time you make a new commit is not only annoying extra work, but it also overwrites history that might be important for the review of that PR (but not important for what ends up in main branch).

* When follow up is requested, you can just tack on new commits, and reviewers can easily see what new code was added since their last review. If you had to force overwrite your whole commit chain for the PR, this becomes very annoying and not useful to reviewers.

* In the end, squash merge means you clean up things once, instead of potentially many times

Re: Git commands I run before reading any code

#116

Post by 8cvor6j844qw_d6 »

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…

> AI generated commit messages

git log --oneline and a sprinkle of your personal sauce on .claude goes a long way :)

Re: Git commands I run before reading any code

#117

Post by esafak »

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

Not a model, but a product: warp.dev

Re: Git commands I run before reading any code

#118

Post by mikepurvis »

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…

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.

Re: Git commands I run before reading any code

#119

Post by grepsedawk »

JetSetIlly wrote: post #10

Some nice ideas but the regexes should include word boundaries. For example: git log -i -E --grep="\b(fix|fixed|fixes|bug|broken)\b" --name-only --format='' | sort | uniq -c | sort -nr | head -20 I have a project with a large package named "debugger". The presence of "bug" within "debugger" causes the original command to go crazy.

Good catch, that's better

Re: Git commands I run before reading any code

#120

Post by jollyllama »

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?

Yeah, the truth is going to be a lot more subtle than this.
Post reply on HN