News for hackers. Stuff that matters.
Re:Julia Evans: Git rebase, what can go wrong by rhinoceraptor on Monday November 06, 2023 @05:08PM (#38169762)
There is obviously a point where you do not want full history. For example, it would absurd to use your editor's undo history tree with keystroke level granularity as your VCS, because in most of those points in history, the code won't even compile because you were in the middle of typing a word.

If your goal is to be able to revert the codebase to a previous version, then you want your history to a series of well prepared, atomic changes where at each point the software is actually functional.

Re:Julia Evans: Git rebase, what can go wrong by naasking on Monday November 06, 2023 @06:26PM (#38170735)
Clearly that's the reason you make a commit to begin with. Erasing that commit history is just silly.
Re:Julia Evans: Git rebase, what can go wrong by seba_dos1 on Tuesday November 07, 2023 @10:40PM (#38186476)
There are a lot of reasons to make a commit other than wanting to make an atomic change meant to be integrated onto shared repository. Ignoring those is just silly.
Re:Julia Evans: Git rebase, what can go wrong by naasking on Friday November 10, 2023 @07:38AM (#38218118)
I never said otherwise. I agree 100%, but this seems like an orthogonal point to what we're discussing here.
Re:Julia Evans: Git rebase, what can go wrong by rhinoceraptor on Wednesday November 08, 2023 @08:21PM (#38199697)
I make a commit whenever I want to save my progress, and rarely is it ever in a state that could even be called a "version" of the software that one would want to revert to, until my feature branch is complete and ready for code review.

At that point I have a much better idea of the scope of my changes, and I can revise them into a few coherent commits, rather than a mess of "WIP" commits that are not a useful history to keep.

Re:Julia Evans: Git rebase, what can go wrong by naasking on Friday November 10, 2023 @07:36AM (#38218104)
> and I can revise them into a few coherent commits,

Why bother with this step at all? It's literally pointless and serves only to stroke a silly aesthetic preference.

> rather than a mess of "WIP" commits that are not a useful history to keep.

I also disagree that WIP commits are not useful history. You might have explored 2 or 3 different abstractions to solve a problem, and picked one but it turned out to be the wrong one, and one of the others would have been a better choice, but now you've lost the history where you explored these options. Are you suggesting it's no loss to erase those other commits and the context around which you thought it wasn't a good choice?