@cleverthis @freemo I would heavily recommend looking into git-compatible tools like jujutsu that let you tinker first and commit later without all the mental overhead required to pre-plan your commits in advance. Sometimes as you go down the rabbit hole when fixing an issue or adding a feature, the easiest thing to do is finish and worry about organization afterwards and tools like jujutsu, (and pijul/DARCS) give you more flexibility than hit in this regards (and it’s easier to keep track of and keep a clean history IMO).
Conversation
Notices
-
Embed this notice
John BS (johnabs@qoto.org)'s status on Wednesday, 30-Apr-2025 21:49:48 JST John BS
-
Embed this notice
🎓 Doc Freemo :jpf: 🇳🇱 (freemo@qoto.org)'s status on Wednesday, 30-Apr-2025 21:49:46 JST 🎓 Doc Freemo :jpf: 🇳🇱
Its hard for me to see how that could work, but if the tool does what you say and does it well somehow that could be a game changer.
-
Embed this notice
John BS (johnabs@qoto.org)'s status on Thursday, 01-May-2025 14:38:52 JST John BS
@freemo @cleverthis Basically, each change you make is logged as a micro-commit, and once you reach a state that you're happy with the current progress, you simply quash the micro commits into commits based on whatever best practices you prefer. In git, such a set of operations would be a nightmare, but jj uses first-class conflicts and a pseudo-theory-of-patches to make this the default way of interacting with your repo, and I have to say I much prefer it. And the fact that any valid jj repo is also a valid git repo means way less overhead in terms of integrating with your existing workflows.
Here's a the codebase and a few tutorial resources.
https://kubamartin.com/posts/introduction-to-the-jujutsu-vcs/
https://steveklabnik.github.io/jujutsu-tutorial/introduction/what-is-jj-and-why-should-i-care.html
Additionally, there are some Emacs extensions and CLI tools that exist. If you're interested, I'll link you :)
-
Embed this notice
mzan (mzan@qoto.org)'s status on Thursday, 01-May-2025 20:39:02 JST mzan
@freemo imagine having a tree of messy private commits. You can: merge them; split them; reorder them; branch them; move commits into different parts of the tree; improve their name or description; undo/redo some of these private operations; and so on.
You work in complete freedom because it is a private tree of commits. The structure of the tree is a first class citizien of the tool, and it is an ever changing structure.
When a commit is in good shape and ready to be published, it become a public commit, and you cannot anymore change it.
The public commits are a linear order of high-quality commits. The last public commit become the new root of the messy tree of your private commits.
-
Embed this notice