points
7 days ago
| 2 comments
| HN
But that is the thing, it is not exposed as an implementation detail, it is a skipable part of the user model.
steveklabnik
7 days ago
[-]
It’s not really skippable because you have to know about it in order to skip it. And a lot of commands interact with it, and so it adds complexity to those commands, git reset being the most obvious case. But even stuff like rebase. Lots of commands that need to abort on a dirty working tree just simply work in jj.
reply
pm215
7 days ago
[-]
I find myself from time to time with stuff in the index (merge conflicts in particular I think can result in this). I never put anything there explicitly. I would love to be able to configure git such that the index didn't exist, but I can't.
reply
1718627440
6 days ago
[-]
The transparent thing would be to put everything into the index, and configure all the commands to autoupdate the index. This is what happens with the merge conflict, because there is no benefit having resolved merge conflicts not already in the index. So the merge conflicts already do what you want, the other commands need to be modified.
reply
pm215
6 days ago
[-]
That isn't what I want, though. I don't see any point in the index as a construct -- I am happy with changes being either (a) not in any commit, just in the working directory or (b) in the most recent commit. Somewhere lurking in the middle is just confusing.
reply
1718627440
5 days ago
[-]
I constantly have something different in the index, that is neither in the commit nor in the workspace, and I find that useful.
reply