The original comment was "drop the index for being "too complicated"". Having to go from "working tree -> index -> committed". In comparison Mercurial only has working "tree -> committed" and Jujutsu only has "committed". The idea of dropping the index is to avoid having extra states changes must pass through. Technically Jujutsu still has the index, as it uses libgit, but the concept isn't exposed to the end user.
this will just lead to more devs not caring about properly splitting up changes
I strongly disagree. jj split reduces the friction in splitting commits. Just think what you have to do to split a commit with git following your 2 step guidance. git reset HEAD~ && git add -p commit && git add -A && git commit. It's even worse for jj split -r @-- (split the 2nd to last commit (ignoring your working commit)). For git you have to do git rebase -i HEAD~2 && git add -p commit && git add -A && git commit && git rebase --continue. In the interactive rebase ui you select the 2nd to last commit to be edited. People avoid splitting with git because there is too much friction. It takes too many commands. It's hard to remember. You can screw up and waste even more time. If you want to encourage devs to split up commits then make it easy to do.
The original comment was "drop the index for being "too complicated"".
Correct. Lots of alternative git frontends drop the index and force you to include all changes in the commit, because they think users find the concept of staged vs unstaged changes confusing. This one doesn't.
That isn't accurate. Jujutsu doesn't even let you have untracked, working, or staged changes as everything is always committed (except for what's in .gitignore). Any change you make will be forced to be part of your current commit.
I never said anything about splitting a commit. My entire point was about creating commits from current changes, either with or without the index. And how I prefer the git way that is two steps because of the index, so it's more helpful to commit what is related instead of everything at once. But it's okay, sometimes we misunderstand.
Jujutsu is the topic of this comment section and in Jujutsu all changes are always part of a commit, so splitting commits is the only way to separate changes into their own commits. And yes, with git I have wanted to retroactively split commits apart too. I don't always get everything perfect on the first try and may want to move certain changes from one commit to another.
Comments
The original comment was "drop the index for being "too complicated"". Having to go from "working tree -> index -> committed". In comparison Mercurial only has working "tree -> committed" and Jujutsu only has "committed". The idea of dropping the index is to avoid having extra states changes must pass through. Technically Jujutsu still has the index, as it uses libgit, but the concept isn't exposed to the end user.
I strongly disagree. jj split reduces the friction in splitting commits. Just think what you have to do to split a commit with git following your 2 step guidance. git reset HEAD~ && git add -p commit && git add -A && git commit. It's even worse for jj split -r @-- (split the 2nd to last commit (ignoring your working commit)). For git you have to do git rebase -i HEAD~2 && git add -p commit && git add -A && git commit && git rebase --continue. In the interactive rebase ui you select the 2nd to last commit to be edited. People avoid splitting with git because there is too much friction. It takes too many commands. It's hard to remember. You can screw up and waste even more time. If you want to encourage devs to split up commits then make it easy to do.
Correct. Lots of alternative git frontends drop the index and force you to include all changes in the commit, because they think users find the concept of staged vs unstaged changes confusing. This one doesn't.
That isn't accurate. Jujutsu doesn't even let you have untracked, working, or staged changes as everything is always committed (except for what's in .gitignore). Any change you make will be forced to be part of your current commit.
I never said anything about splitting a commit. My entire point was about creating commits from current changes, either with or without the index. And how I prefer the git way that is two steps because of the index, so it's more helpful to commit what is related instead of everything at once. But it's okay, sometimes we misunderstand.
Jujutsu is the topic of this comment section and in Jujutsu all changes are always part of a commit, so splitting commits is the only way to separate changes into their own commits. And yes, with git I have wanted to retroactively split commits apart too. I don't always get everything perfect on the first try and may want to move certain changes from one commit to another.
Thank you for explaining again why I prefer git.