4 ms·

> my commit history got much cleaner with jj In my opinion the traditional git workflow is flawed, but wanting the commit history to be cleaner is fundamentall

> my commit history got much cleaner with jj In my opinion the traditional git workflow is flawed, but wanting the commit history to be cleaner is fundamentally the wrong approach. There are basically two main reasons to look at a chronological list of commits: reading it as a changelog, and bisecting to find a bug. As a changelog, you want the history to be clean, organized, and concise. Rebase-based workflows are good for this and it's what Jujutsu excels at. For bug hunting, every commit should build successfully and be a faithful representation of what was on the developer's machine at the time they made the commit. Merge-based workflows are good for this. But these are conflicting requirements. If you optimize for readability, you lose reproducibility and vice-versa. To achieve both you need to stop trying to use commit histories as a changelog. It doesn't matter how messy it is if you never look at it. But then you need some kind of history to look at. Personally I haven't seen any open source tools that solve this well enough to be a viable alternative. Stacked diffs are probably the closest. I like Jujutsu but it feels more like an incremental improvement over Git as opposed to something that actually addresses the deeper issues of VCS.

widdershins 2y ago
> For bug hunting, every commit should build successfully and be a faithful representation of what was on the developer's machine at the time they made the commit. Merge-based workflows are good for this. I'm not quite sure how that follows - I commit things all the time that cause either the main build or tests to fail. And a faithful representation of what was on my machine at a certain time in the past doesn't help me find bugs. What helps is when each commit represents a single atomic change that I can easily understand, it has a clear commit message and it builds and the tests pass. To acheive this I often need to rewrite history, but doing so doesn't diminish my ability to find where I introduced bugs later on. So I feel that rebase workflows are better for both readability _and_ bisection.
- Asraelite 2y ago
  You can squash locally, that's fine, so long as you then locally run tests on the new squashed commit before pushing. What I think is problematic is rebasing entire branches weeks after their commits have last been touched. The more you rely on manually looking through commit histories, the more you're encouraged to do this. EDIT: something I forgot to mention in my original comment as well is that it rebasing makes collaboration harder. Basically, overall, we spend a lot of effort working around the drawbacks of rebasing, when we should be trying to eliminate the need to rebase in the first place.

widdershins 2y ago

> For bug hunting, every commit should build successfully and be a faithful representation of what was on the developer's machine at the time they made the commit. Merge-based workflows are good for this. I'm not quite sure how that follows - I commit things all the time that cause either the main build or tests to fail. And a faithful representation of what was on my machine at a certain time in the past doesn't help me find bugs. What helps is when each commit represents a single atomic change that I can easily understand, it has a clear commit message and it builds and the tests pass. To acheive this I often need to rewrite history, but doing so doesn't diminish my ability to find where I introduced bugs later on. So I feel that rebase workflows are better for both readability _and_ bisection.

Asraelite 2y ago
You can squash locally, that's fine, so long as you then locally run tests on the new squashed commit before pushing. What I think is problematic is rebasing entire branches weeks after their commits have last been touched. The more you rely on manually looking through commit histories, the more you're encouraged to do this. EDIT: something I forgot to mention in my original comment as well is that it rebasing makes collaboration harder. Basically, overall, we spend a lot of effort working around the drawbacks of rebasing, when we should be trying to eliminate the need to rebase in the first place.