Git rebase, what can go wrong • Hacker News Board

Re: Git rebase, what can go wrong

#401

Post by funcDropShadow » Fri, Nov 10, 2023, 10:19 AM UTC

watwut wrote: post #225

bonzini wrote: post #206

Earlier quoted context omitted.

The point of the parent comment is exactly that you should clean up the history before merging to a public branch, so that you can use bisect, even if so far you had wip wip doh wip as the commit messages. The way to get there is to have a mix of proper and wip commits.

Frankly, people lately spend more time managing commit history then using it. Like, commit history is useful once in a year little bit, maybe, but we spend absurd amount of time trying to make it look nice.

I use the commit history every time a I open file I haven't worked on for a while. Just seeing the output of git annotate in the border of Intellij gives me a sense how old code is, what changed together with what and whom to ask in case of questions.

Re: Git rebase, what can go wrong

#402

Post by naasking » Fri, Nov 10, 2023, 12:36 PM UTC

rhinoceraptor wrote: post #393

naasking wrote: post #319

Earlier quoted context omitted.

Clearly that's the reason you make a commit to begin with. Erasing that commit history is just silly.

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

> 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 an (IMO) 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 at the time?

Re: Git rebase, what can go wrong

#403

Post by naasking » Fri, Nov 10, 2023, 12:38 PM UTC

seba_dos1 wrote: post #382

naasking wrote: post #319

Earlier quoted context omitted.

Clearly that's the reason you make a commit to begin with. Erasing that commit history is just silly.

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.

I agree 100%, and never said otherwise, but this seems like an orthogonal point to what we're discussing here.

Re: Git rebase, what can go wrong

#404

Post by spider-mario » Sat, Nov 11, 2023, 9:43 AM UTC

BeetleB wrote: post #248

duped wrote: post #134

Earlier quoted context omitted.

The point of a clean git history is not to have a clean git history. The point is to make it possible to debug later, via bisect, or show, or even just a diff. The point is to make the workspace clean for the next guy. Instead of letting it go, maybe we should have more discipline and organization in our lives and not less.

It's hard to tell what side you're on, because both sides refer to their stance as "clean history". The pro-revisionists (squash, rebase) say they do what they do so the history looks clean (no intermediate commits breaking stuff, a "straight line" graph, etc) The anti-revisionists say they do what they do so the history looks clean (can see the actual development, can safely diff different commits to see what change…

> > The point is to make it possible to debug later, via bisect, or show, or even just a diff.

> This sounds anti-revisionist.

That’s not how I see it. What makes debugging via bisecting easier is self-contained changes, not exactly chronological changes where you temporarily broke stuff and then fixed it before submitting your PR.