Hey! Mostly just rebase out of habit actually, but I've been exploring --update-refs recently.
Two things come to mind that I don't love about `gt`:
- the philosophy of "every commit is a PR" falls apart sometimes. Sometimes I want to logically separate commits in a PR—but not every commit passes CI. This makes it easier to review. Or call out optional changes that can easily be dropped.
- It broke my workflow in a few ways. The one thing I notice the most is that I like to "pop" a commit into staged changes and make edits. So I can easily see a diff of what I'm editing. I expected `gt modify` to do this. So instead I git reset --soft, commit, and `gt submit`
We (Graphite) love Jujutsu – comes up in conversation all the time here.
A prior version of the CLI is open source, the core data model (using git refs to store some extra data about what a branch's parent is) is still the same. https://github.com/withgraphite/graphite-cli
We've talked about supporting other clients, but don't currently have the bandwidth to build something like that – definitely something I am personally passionate about making sure happens at some point.
The funny thing is — this is actually different from how OSS (the initial model that Git was built for) worked. Patches are just applied as a single linear commit to the trunk branch.
Committing the history of individual work to the source of truth remote was definitely not the intent of merges.
You don't lose it long term if you're using GitHub PRs — GitHub keeps the "reflog" (quoted because I imagine their implementation may not actually use reflog) of the branch indefinitely, even after force pushes. Graphite (built to replicate the Phabricator workflow) enables viewing and diffing these versions. (disclaimer, I helped build this)
Phabricator and Gerrit both do a really good job of this. To me Git works fine as a pure "version control" system, but the process of collaborating on a branch before it gets merged into a shared branch seems to be beyond the scope of version control -- something that a higher layer tool is ideal for.
Net new feature development is often 20% or less of the job. With most guidelines like this, it's always possible to find exceptions -- but understanding why you're making the tradeoff in that situation is key.
With that said, using methods like stacking and feature flagging, I've been finding even new feature development to be possible while keeping my PRs to roughly 5 files changed or less.
I like this take. The onus is on these devs to learn how to use available tools effectively to split up their changes.
There's a clear parallel here to the idea of a "genius" who isn't able to communicate their ideas effectively. Can they really be considered that smart if no one understands them?
reply