[roblh]

Maybe I'm just a scrub, but something that I find makes it harder to do smaller commits is that I frequently rely on being able to see which lines I've changed directly inline in my editor. When you commit, vscode now stops highlighting all of those lines, and that makes it much more difficult for me to orient myself relative to what I've already done. The individual lines, and the git pane that shows which files have been changed, act as waypoints for me while I'm working on stuff. It's particularly important on more complicated features that span more files, and I'll often intentionally commit stuff I feel like I'm not likely to touch again to reduce some visual noise.

[conradludgate]

My recommendation: don't treat the development process as the final draft.

Write everything in one go, and then afterwards rework the commits to tell the story you want to tell. This does require getting very comfortable with git rebase, but I can absolutely recommend it.

Using this technique, I've managed to merge several large refactors lately with no issues, and the reviewers didn't hate me.

[kiitos]

holy moly absolutely not

git is a means, not an end

code review is about the code as a unit whole, not the steps along the way!

[TiredGuy]

I agree this can be a bit of a pain if you're used to that. There are ways to partially reduce it: 1. use the timeline panel for an individual file to see all the historical changes to a file, and you can highlight multiple ones to see cumulative changes, and you can filter to only git commits or only local changes etc. 2. use the commit history panel in the source control area to do the same across commits, but it doesn't allow you to highlight across commits for cumulative changes

It does require a bit of a paradigm shift sometimes to not rely as much on seeing all cumulative changes for the ticket highlighted as you code, and instead compartmentalize your immediate view to the current commit's task, but often the above 2 alternatives help suffice. Of course, you did mention that you'll commit stuff you're not likely to touch again, which helps a lot too

[crazygringo]

That's really interesting.

Seems like it would be even better if VS Code provided a way to highlight all lines changed relative to a particular commit like the start of a branch. Maybe it's worth filing a feature request?

(I don't use VS Code this way so I'm assuming it doesn't already have this.)

[mixmastamyk]

I commit early and often, then push the feature branch to gitlab, etc. Then I look at the draft merge-req diff in the browser.

Meaning, I can keep committing while also able to see the full changes evolve.

[t-writescode]

This sounds like a real and valid incompatibility with a high frequency commit cadence.

If you’re interested in trying these strategies anyway, does your editor of choice have an inline “git blame”? In IntelliJ, I can see who and when committed the most recent change in the line around the one I’m working on.

It doesn’t resolve the “which files have I worked on” issue; but it might help the others? Not as nice as a different colored line like uncommitted code would otherwise be highlighted, but it could be enough of a step in that direction?

[notapenny]

Couldn't you use something like GitLens for that? I haven't used it in a bit but IIRC it lets you see your changes versus any branch pretty easily. Personally if I do feel the need for a view of what I've touched, I just open up a draft PR.

[roblh]

You certainly can, I specifically like being able to see it in real time though. It’s less useful if it isn’t constantly present without having to bring it up with a click/command.

[mnembrini]

In Intellij if you open a PR it will highlight lines that have changed in the PR differently (even from multiple commits) and you can click on the colored border to see the version of the code on the main branch

[rd]

you could probably write an extension to accomplish this in a couple of days with GPT-5 now

[hypeatei]

  git add --patch

...is your friend if you want to leave all your changes unstaged for awhile then break it out into multiple commits later.

[t-writescode]

To add, when I’m breaking my changes down into multiple parts for review, I tend to:

  * squash everything I’ve done into one commit
  * create a new branch off main/master that will be the “first commit”
  * cherry-pick changes (easy from some git guis) that represent a modular change.
  * push and make an MR from the new branch
  * rebase “the big commit” on top of the partial change.
  * wash, rinse and repeat for each change, building each MR off its requisite branch.

The squashing part is vital because otherwise you enter merge conflict hell with the rebase.