undefined | Better HN

0 pointsArnavion2y ago0 comments

Based on the description in the article, it does the equivalent of `git add`ing every change by default, but allows you to choose a subset of those changes to be in the actual commit. So the net effect is the same as if nothing was `git add`ed by default and I ran `git add -p` to choose the subset of changes to be in the actual commit, which is what I use the index for.

0 comments

3 comments · 1 top-level

charcircuit2y ago· 2 in thread

It's not the same. With git you are doing 2 operations, adding some changes to the index and then commiting. With jujutsu you do 1 operation, splitting a commit. Yes, the end result is the same, but since git has the concept of the index, it requires an extra step and is more complex to understand.

kuschkufan2y ago

You guys are just discussing different points. OP comment was about being something like index functionality being available at all in a vcs (or git frontend). Yours is about how working with that index functionality is a one step operation while with git it is two (add + commit).

I happen two think that two steps are better. If every new and changed file is automatically included in the next commit this will just lead to more devs not caring about properly splitting up changes into logical and related commits. Just commit everything in a single commit, push, home time! For those people the two step process seems a needless waste. For me it's to encourage devs to only add related changes into a single commit.

charcircuit2y ago

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.

2 more replies

j / k navigate · click thread line to collapse