upvote

points

by eviluncle19 hours ago |
comments
upvoteby fmbb19 hours ago|
[-]
Editing local files is not where you control your source code I hope.

Just tell Claude to never commit or push.

You are in control of git, Claude is simply a tool to quickly apply changes to local files for something you want.

reply
upvoteby watwut19 hours ago|
parent|
next
[-]
Yes, why should we do the things in easier and more comfortabke way (review small changes) when we can force user into harder one (newest changes mixed with all previous ones).
reply
upvoteby number618 hours ago|
parent|
[-]
I just review the MR
reply
upvoteby imtringued18 hours ago|
parent|
[-]
So basically you gave up?
reply
upvoteby fmbb17 hours ago|
parent|
[-]
What does this mean?

A Merge Request or Pull Request is the only thing that makes sense to review, and always has been since before LLMs.

If some author tells me “you can review each commit to make it easy” I will ask them to make separate PRs.

reply
upvoteby soon_to_be_sb14 hours ago|
parent|
next
[-]
>A Merge Request or Pull Request is the only thing that makes sense to review, and always has been since before LLMs.

Why doesn't it make sense to review smaller units of change within a big PR?

reply
upvoteby skydhash14 hours ago|
parent|
[-]
Not GP, but in my experience, those small changes are usually contrived to be small. Like saving snapshots instead of being atomic and self contained. And if they are the latter, they should have been separate PR.

That’s why I usually look at the diff of the whole PR and prefer to merge by squashing. Commits inside the PR are usually noise.

reply
upvoteby soon_to_be_sb12 hours ago|
parent|
[-]
What you are saying is true if created manually. It is a chore to create sensible commits messages when you are committing often.

But LLMs appear to be pretty good at making small commits with sensible commit messages, that greatly help to make sense of the whole PR.

Regarding large monolithic commits, how do you even know where to start reviewing in a large PR? Smaller commits at least give you some sense of ordering.

reply
upvoteby skydhash9 hours ago|
parent|
[-]
> Regarding large monolithic commits, how do you even know where to start reviewing in a large PR?

What I’m saying is that large commits shouldn’t be a thing without out of band discussions (formatting, design refactoring, features merging). With such knowledge, it’s easy to glance at the code and understand the implementation.

reply
upvoteby soon_to_be_sb27 minutes ago|
parent|
[-]
>without out of band discussions..

Not every project can afford this.

>With such knowledge, it’s easy to glance at the code and understand the implementation.

I really doubt that this is true for large, legacy code bases, where one is only familiar with a small part of the system.

reply
upvoteby watwut15 hours ago|
parent|
prev|
[-]
It means you gave up on getting claude to show you changes as it is doing them, in a comfortable form, so that you can steer it as it is doing them.
reply
upvoteby imtringued18 hours ago|
parent|
prev|
[-]
Nothing more comfortable than having to use git commits and branching just for telling the agent which lines it messed up instead of simply not writing the garbage in the first place.
reply