4 ms·
> 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. Debuggabi
by nextaccountic 5mo ago
> 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
- bschwindHN 5mo agoJust 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.
- paradox460 5mo agoJj could do that; it stores an evolog of each change, but currently that's kept local
- gmueckl 5mo agoI 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.
- riwsky 5mo agoThat’s, uh, exactly how jj works!
- gmueckl 5mo agoI 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.
- steveklabnik 5mo ago> 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.
- Izkata 5mo agoForce --no-ff merges in git. That's pretty much what you want.