Comment by block_dagger
11 hours ago
Having no such thing as an uncommitted change seems like it would be a nightmare, but perhaps I'm just too git-oriented.
11 hours ago
Having no such thing as an uncommitted change seems like it would be a nightmare, but perhaps I'm just too git-oriented.
> Having no such thing as an uncommitted change seems like it would be a nightmare, but perhaps I'm just too git-oriented.
Why? What's the problem you see? The only problem I see is when you let these extra commits pollute the history reachable from any branch you care about.
Let's look at the following:
Internally, 'git stash' consists of two operations: one that makes an 'anonymous' commit of your files, and another that resets those files to whatever they were in HEAD. (That commit is anonymous in the sense that no branch points at it.)
The git libraries expose the two operations separately. And you can build something yourself that works similarly.
You can use these capabilities to build an undo/redo log in git, but without polluting any of the history you care about.
To be honest, I have no clue how Jujutsu does it. They might be using a totally different design.
> perhaps I'm just too git-oriented.
The problem is git's index let's you write a bunch of unconnected code, then commit it separately. To different branches, even! This works great for stacking diffs but is terribly confusing if you don't know what you're doing.
Things like the index become a workflow pattern, rather than a feature, if that makes any sense.