For me the point of splitting commit is not for documentation (though it can be an added benefit). It is so that you can easily rollback a feature, or cherry pick, it also makes the use of blame and bisect more natural. Anyways, that's git, it gives you a lot of options, do what you want with them. If a big end-of-day commit is fine for you, great, but some people prefer to work differently.

But that's not actually the reason I use "git add -p" the most. The way I use it is to exclude temporary code like traces and overrides from my commits while still keeping them in my working copy.

▲

chrisweekly a day ago | parent [-]

Hmm, this idea of maintaining working copies that differ from upstream strikes me as fragile and cumbersome. For a solo project, sure, whatever works. But for larger projects, IMHO this workflow is an antipattern.

▲

GuB-42 a day ago | parent [-]

To be fair, yes, it is a bit fragile and cumbersome, though it works for me.

However, it doesn't makes "git -p" less useful when the idea is to separate what you want to publish and what you want to keep in your work zone, be is your working copy or a dev branch.

As always with git, it is not very opinionated, it lets users have their own opinions, and they do! Monorepos vs many repos, rebase vs merge, clean vs honest history,... it can do it all, and I don't think the debates will ever settle on what is an "antipattern" as I don't think there is a single "right" answer.

	▲	chrisweekly 9 hours ago \| parent [-]
		Yeah, TIMTOWTDI, different strokes, etc... and I'm not claiming there's "one true way". I was just reacting (almost viscerally) to the idea of deliberately maintaining diffs in a stateful local env, which feels like it's begging for "works on my machine" issues. My instinct to avoid that, on principle, extends beyond project source code to "fiddly" local dev environments, seeking things like devcontainers, fully-reproducible builds for CI, etc.