3 ms·

> git has lots of bad design choices that are deeper than UI. The index doesn't need to exist. The index is a useful tool. You can opt out with `git commit -a`

> git has lots of bad design choices that are deeper than UI. The index doesn't need to exist. The index is a useful tool. You can opt out with `git commit -a` > There is a lot of state that is not recorded anywhere Examples? > The rebase vs merge disaster ??? How is this a disaster? They serve different purposes and have entirely different semantics. You can use rebase to force fast-forward merges (which do not create merge commits), but I fail to see how this is a disaster.

steveklabnik 2y ago
(Not your original parent, my take) > The index is a useful tool To be clear, jj retains the full power of the git index, without having one. To use git terms, the index is just a normal commit like any other. The index is one of my favorite features of git. I don’t miss it in jj. > Examples? For one… the index! It’s not part of your history. The working directory can contain dirty state that’s not tracked anywhere. Those are the big two off the top of my head. > how is this a disaster? I’m on your side with this one, and jj supports both just fine.
CJefferson 2y ago
My main issues with git are all about version control of branches. Which branches were commits originally created on. What commit was branch X on 2 weeks in the past? (My personal biggest issue) -- there is no way to delete a branch in a version-controlled way (that is, let me un-delete it later). 'reflogs' don't count, I want to be able to version-control my branch deletions. And if people (I'm not accusing you, person I'm replying to, but I get this a lot) say "git isn't for that", well then it's really annoying that git has become "the version control system for everything".
sunshowers 2y ago
To my knowledge there is nothing the git index can do that Jujutsu can't, in a more sensible fashion.
kazinator 2y ago
You cannot "opt out" of the index. It's always sitting there. $ ls -l .git/index When it gets corrupt, though, you can blow it away. It gets rebuilt. The reason it can be casually rebuilt is that there is a copy of it in the HEAD commit. The git index is an intestinal appendix. It has no reason to exist. There is no need to "stage" changes and then move them to a commit. What is called staging should just create a new commit. The index creates duplicity. Many commands operate on both the work tree and index, or separately on either one. Your working tree can differ from the index, which differs from the HEAD commit, so then you have "git diff" (tree to index), "git diff --cached" (index to HEAD) and "git diff HEAD" (tree to HEAD). What's the point of staging a commit, when a commit can be amended? You need staging for something that cannot be easily fixed once it is deployed.
kubanczyk 2y ago
>> The rebase vs merge disaster > ??? How is this a disaster? Not a disaster, but merge was not strictly needed. We could've lived with rebase only. But in git (unlike in jj) rebase is deeply flawed. If you ever needed to resolve the same conflict through several commits you know it. That flawed git implementation is why people kept using merge yo solve the problem on a single final commit.
OJFord 2y ago
> You can opt out with `git commit -a` I wish you couldn't!

steveklabnik 2y ago

(Not your original parent, my take) > The index is a useful tool To be clear, jj retains the full power of the git index, without having one. To use git terms, the index is just a normal commit like any other. The index is one of my favorite features of git. I don’t miss it in jj. > Examples? For one… the index! It’s not part of your history. The working directory can contain dirty state that’s not tracked anywhere. Those are the big two off the top of my head. > how is this a disaster? I’m on your side with this one, and jj supports both just fine.

CJefferson 2y ago

My main issues with git are all about version control of branches. Which branches were commits originally created on. What commit was branch X on 2 weeks in the past? (My personal biggest issue) -- there is no way to delete a branch in a version-controlled way (that is, let me un-delete it later). 'reflogs' don't count, I want to be able to version-control my branch deletions. And if people (I'm not accusing you, person I'm replying to, but I get this a lot) say "git isn't for that", well then it's really annoying that git has become "the version control system for everything".

sunshowers 2y ago

To my knowledge there is nothing the git index can do that Jujutsu can't, in a more sensible fashion.

kazinator 2y ago

You cannot "opt out" of the index. It's always sitting there. $ ls -l .git/index When it gets corrupt, though, you can blow it away. It gets rebuilt. The reason it can be casually rebuilt is that there is a copy of it in the HEAD commit. The git index is an intestinal appendix. It has no reason to exist. There is no need to "stage" changes and then move them to a commit. What is called staging should just create a new commit. The index creates duplicity. Many commands operate on both the work tree and index, or separately on either one. Your working tree can differ from the index, which differs from the HEAD commit, so then you have "git diff" (tree to index), "git diff --cached" (index to HEAD) and "git diff HEAD" (tree to HEAD). What's the point of staging a commit, when a commit can be amended? You need staging for something that cannot be easily fixed once it is deployed.

kubanczyk 2y ago

>> The rebase vs merge disaster > ??? How is this a disaster? Not a disaster, but merge was not strictly needed. We could've lived with rebase only. But in git (unlike in jj) rebase is deeply flawed. If you ever needed to resolve the same conflict through several commits you know it. That flawed git implementation is why people kept using merge yo solve the problem on a single final commit.

OJFord 2y ago

> You can opt out with `git commit -a` I wish you couldn't!