25 ms·

I'm surprised to see an alternative git frontend that doesn't immediately drop the index for being "too complicated", which in turn makes me drop the alternativ

I'm surprised to see an alternative git frontend that doesn't immediately drop the index for being "too complicated", which in turn makes me drop the alternative git frontend for being "too simplistic". I might try this one out.

rqtwteye 3y ago
I think the index is one of the best features of git if you work with a git GUI.
- morsch 3y ago
  It's great even if you don't
- notso411 3y ago
  [dead]
- ilyagr 3y ago
  The article makes a similar point. In theory, this is not an advantage of the idea of the index, but simply a consequence of the fact that no GUIs have yet been written with jj in mind. In practice, this can be a real limitation of jj for people who are used to such GUIs, for now.
charcircuit 3y ago
jj did drop the index. What appeal do you see in git's index? All it's ever done for me is slow me down by needing to do extra commands / arguments which I sometimes forget.
- Arnavion 3y ago
  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.
  - charcircuit 3y ago
    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.
    - kuschkufan 3y 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.
      - charcircuit 3y 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.

rqtwteye 3y ago

I think the index is one of the best features of git if you work with a git GUI.

morsch 3y ago
It's great even if you don't
notso411 3y ago
[dead]
ilyagr 3y ago
The article makes a similar point. In theory, this is not an advantage of the idea of the index, but simply a consequence of the fact that no GUIs have yet been written with jj in mind. In practice, this can be a real limitation of jj for people who are used to such GUIs, for now.

charcircuit 3y ago

jj did drop the index. What appeal do you see in git's index? All it's ever done for me is slow me down by needing to do extra commands / arguments which I sometimes forget.

Arnavion 3y ago
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.
- charcircuit 3y ago
  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.
  - kuschkufan 3y 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.
    - charcircuit 3y 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.