Hacker News Reader

Comment by charcircuit | Hacker News Reader

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.

View on HN

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.

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.

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.

>I never said anything about splitting a commit.

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.

> Jujutsu is the topic of this comment section and in Jujutsu all changes are always part of a commit

Thank you for explaining again why I prefer git.

>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.

>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.

Reply on news.ycombinator.com