Hacker News Reader

Comment by nextaccountic | Hacker News Reader

> Latter commits overwrite work that was done in earlier commits and the story breaks.

> Some people prefer this, as it helps git bisect work better. Debuggability versus reviewer convenience is the tradeoff, I guess.

Ideally we would have a VCS that made ergonomic to store both history-as-it-happened for some purposes, and the cleaned up, squashed and rebased history for other purposes, ensuring they match

View on HN

Just squash all the PR commits into one when it gets merged to main or whatever your main branch is.

You can revisit the original PR to see the individual commits if you really want.

I think that version control has reached a point where the next major evolutionary steps will be based on making history totally shared and immutable with history edits themselves being non-destructive versioned operations that can be browsed as higher order history.

That’s, uh, exactly how jj works!

I never absorbed that fact until now. Now, if it supported huge repositories with large files and binary files well, it could actually become a superstar.

> if it supported huge repositories with large files and binary files well,

In the open source context, it's limited by git here. But you can use jj with Google's monorepo, and so it itself is able to handle at least huge repositories (I don't know how big the largest files and binary files are in it, but I'm assuming that it has some of those too) well. That of course doesn't help you directly if you're not at Google, but the pathway is there.

Jj could do that; it stores an evolog of each change, but currently that's kept local

Force --no-ff merges in git. That's pretty much what you want.

Reply on news.ycombinator.com