Having switched to jj I don't really agree. Everything I do is basically the same as with branches, just that I get randomly generated tip names rather than naming them myself, which is both slightly convenient and slightly annoying
Within my own company, yes. We’ve shipped a lot more features this year with the same number of people. They’re also better features. We get from 0 to 90% in an hour and then still put a lot of effort into that last 10%. The projects have better test coverage, docs, logging, etc. then they did 2 years ago. Stretch goals are reached much more frequently. What used to be 3 week projects are closer to 3 days. Our commit history is cleaner, easier to understand, has has better commit messages because we have Claude rewrite the history before opening the PRs. Our product is faster, more stable, and has nicer UX.
But this is anecdotal. It’s a team of senior devs who already knew the codebase well. We have a ton of detailed guidelines that make sure it’s writing code we deem acceptable. We review each others code, and get LLMs to review, a LOT.
Hey we should see this increase of so called productivity in the global GDP growth numbers. If AI really is this productive the slope of GDP growth should be steeper the last 2~ 3 years. If there is no change in the GDP growth slope, there's no general productivity improvement.
Yeah, my solution to this problem has been to get Claude to use jj to create a clean commit history. Each commit serves a single purpose and includes what drove the decisions we made. You lose the noise and still have the meaning.
So I'm a little unclear as to benefit of this. It sounds...wasteful?
Redescribe, reorder, split, squash, abandon commits is trivial.
Auto-rebasing is fantastic, fix a conflict once and not have to keep correcting.
You can rebase individual commits, ranges of commits, etc. You can also rebase trees I.e. forking branches with a common ancestor, with a single command.
The operation log also makes it feel super safe. You can always undo a jj operation or restore to a past state
I think what you’re talking about is real, but it’s only part of the problem. The issue is it’s poor design. There’s a lack of consistency that is really off putting. Spacing is inconsistent and doesn’t create a sense of visual hierarchy. Buttons, inputs, selects, call-outs, table cells are barely distinguishable from each other, but also inconsistent within their own categories. The copy is also confusing. I don’t even know what this does.
History is immutable ONCE it’s merged. Prior to that, it’s malleable. We rewrite our branch history fairly often. I’ll take a big PR that’s ready, and rewrite the history in a way that tells clear story. This lets me stack PRs so it’s easier for coworkers to digest the work. It hides the messy reality of how it was constructed. It lets the development process follow evolutionary design, without review being miserable at the end of the day. This also makes git-blame 6 months later way more useful, as the commits end up much tidier with better messages and clearer story being told.
I'm missing a good way to turn on/off plugins and settings depending on the directory. Eg turning off rust-analyzer on some projects, or using pyright instead of mypy as the LSP.
Anyways