5 ms·

> You lost me at "free from the index". If you click the link that text points you to (i.e. https://github.com/martinvonz/jj/blob/main/docs/git-comparison.md#t

> You lost me at "free from the index". If you click the link that text points you to (i.e. https://github.com/martinvonz/jj/blob/main/docs/git-comparison.md#the-index https://github.com/martinvonz/jj/blob/main/docs/git-comparis...), there's an explanation there for how to achieve the same workflows. I get that it's different, but I don't think it's worse. I consider myself a (former) git power user (I think I have ~90 patches in Git itself) and I've never missed the index since I switched to Mercurial ~7 years ago. > This is very welcome. Thanks :)

omegalulw 5y ago
> With Jujutsu, you'd instead use jj split to split the working copy commit into two commits. This is more confusing? Often times when debugging/writing a fix I would have extraneous code that I wouldn't want to commit. With an index I'm always sure if what I commit, but with this workflow you have to keep track of such stuff all the time and if you forget that stuff makes it in? Not to mention that another benefit of an index is being able to change commits and git replaying your working diff.
- em-bee 5y ago
  yeah, i feel this is going to bother me, or at least be difficult to get used to. i often have temporary files that i do not want to commit, nor do i want to add them to .gitignore (because i want to commit them later) but then, i'll have to spend some time using jj split. if it is powerful enough then maybe the end result is just that those files only live in the last commit. also, what happens on push? i'd never ever want the working copy to be pushed to the remote repo. i could not find anything in the documentation about that. (according to the answer here: https://news.ycombinator.com/item?id=30399554 https://news.ycombinator.com/item?id=30399554 the working copy is not supposed to be pushed)
- joseph8th 5y ago
  Yah... I have a long-standing habit of commenting `TODO` for some debugging or WIP code. Then, before I commit, I can just do `git diff | grep TODO` and see all the new TODOs I've added.
alwillis 5y ago
Something that’s backend compatible with Git but uses some of Mercurial’s sensibilities? Sign me up!
- buck4roo 5y ago
  https://hg-git.github.io/ https://hg-git.github.io/ Happy user for at least 6 years. The sanity of Mercurial's UX cannot be overstated.
cryptonector 5y ago
You cover `git add -p`, but I want `git add -e`. Also, I often rebase and `edit` commits to split them or undo parts of them. Rebase and all this is all about making commits that have just the right content, and keeping history clean and linear. The tools have to make this possible and easy. I get that git feels... barebones for this. You really have to understand what you're doing when using git like I do, so I get that it's not very accessible. Better UIs are great, but on the other hand, we need to be able to get down to the low level. IMO.
- martinvonz 5y ago
  > You cover `git add -p`, but I want `git add -e`. Interesting. I don't think I've heard anyone use `git add -e` before. It should be easy to add that feature, but it would be very low priority since so few users seem to like to manually edit patches. > Also, I often rebase and `edit` commits to split them or undo parts of them. You can do that by checking out the commit, then `jj squash/amend` (aliases) and all descendants will be automatically rebased on top, and branches pointing to them will be updated too. There's also `jj edit` for editing the changes in a commit without updating to it. And there's `jj split` for splitting a commit (without needing to update to it). > Rebase and all this is all about making commits that have just the right content, and keeping history clean and linear. The tools have to make this possible and easy. Yes, that's definitely a goal. I think Jujutsu does a much better job at that than Git does. Did you read https://github.com/martinvonz/jj#comprehensive-support-for-rewriting-history https://github.com/martinvonz/jj#comprehensive-support-for-r...?
  - cryptonector 5y ago
    I did, and it's almost certainly nicer than Git for commit splitting. But even though I might use a tool specifically designed for user-friendly commit splitting, I still want: `git add -e`, `git diff --staged` (to see what I added with `git add -e`) vs `git diff` (to see what I left out), and `git commit` w/o `-a` to commit the contents of the index. This is easier for me than `$WHATEVER commit` followed by `$WHATEVER`'s commit splitting method. That said, I have to congratulate you again on not taking the ugh-rebase-rewrites-history/history-rewrite-bad road. This is a huge step forward for DVCS. It may well be that what rebase workflows needed was a UI that non-power users could use. While we're at it, I wonder what you think of this: https://gist.github.com/nicowilliams/ea2fa2b445c2db50d2ee6509c3526297 https://gist.github.com/nicowilliams/ea2fa2b445c2db50d2ee650...

omegalulw 5y ago

> With Jujutsu, you'd instead use jj split to split the working copy commit into two commits. This is more confusing? Often times when debugging/writing a fix I would have extraneous code that I wouldn't want to commit. With an index I'm always sure if what I commit, but with this workflow you have to keep track of such stuff all the time and if you forget that stuff makes it in? Not to mention that another benefit of an index is being able to change commits and git replaying your working diff.

em-bee 5y ago
yeah, i feel this is going to bother me, or at least be difficult to get used to. i often have temporary files that i do not want to commit, nor do i want to add them to .gitignore (because i want to commit them later) but then, i'll have to spend some time using jj split. if it is powerful enough then maybe the end result is just that those files only live in the last commit. also, what happens on push? i'd never ever want the working copy to be pushed to the remote repo. i could not find anything in the documentation about that. (according to the answer here: https://news.ycombinator.com/item?id=30399554 https://news.ycombinator.com/item?id=30399554 the working copy is not supposed to be pushed)
joseph8th 5y ago
Yah... I have a long-standing habit of commenting `TODO` for some debugging or WIP code. Then, before I commit, I can just do `git diff | grep TODO` and see all the new TODOs I've added.

alwillis 5y ago

Something that’s backend compatible with Git but uses some of Mercurial’s sensibilities? Sign me up!

buck4roo 5y ago
https://hg-git.github.io/ https://hg-git.github.io/ Happy user for at least 6 years. The sanity of Mercurial's UX cannot be overstated.

cryptonector 5y ago

You cover `git add -p`, but I want `git add -e`. Also, I often rebase and `edit` commits to split them or undo parts of them. Rebase and all this is all about making commits that have just the right content, and keeping history clean and linear. The tools have to make this possible and easy. I get that git feels... barebones for this. You really have to understand what you're doing when using git like I do, so I get that it's not very accessible. Better UIs are great, but on the other hand, we need to be able to get down to the low level. IMO.

martinvonz 5y ago
> You cover `git add -p`, but I want `git add -e`. Interesting. I don't think I've heard anyone use `git add -e` before. It should be easy to add that feature, but it would be very low priority since so few users seem to like to manually edit patches. > Also, I often rebase and `edit` commits to split them or undo parts of them. You can do that by checking out the commit, then `jj squash/amend` (aliases) and all descendants will be automatically rebased on top, and branches pointing to them will be updated too. There's also `jj edit` for editing the changes in a commit without updating to it. And there's `jj split` for splitting a commit (without needing to update to it). > Rebase and all this is all about making commits that have just the right content, and keeping history clean and linear. The tools have to make this possible and easy. Yes, that's definitely a goal. I think Jujutsu does a much better job at that than Git does. Did you read https://github.com/martinvonz/jj#comprehensive-support-for-rewriting-history https://github.com/martinvonz/jj#comprehensive-support-for-r...?
- cryptonector 5y ago
  I did, and it's almost certainly nicer than Git for commit splitting. But even though I might use a tool specifically designed for user-friendly commit splitting, I still want: `git add -e`, `git diff --staged` (to see what I added with `git add -e`) vs `git diff` (to see what I left out), and `git commit` w/o `-a` to commit the contents of the index. This is easier for me than `$WHATEVER commit` followed by `$WHATEVER`'s commit splitting method. That said, I have to congratulate you again on not taking the ugh-rebase-rewrites-history/history-rewrite-bad road. This is a huge step forward for DVCS. It may well be that what rebase workflows needed was a UI that non-power users could use. While we're at it, I wonder what you think of this: https://gist.github.com/nicowilliams/ea2fa2b445c2db50d2ee6509c3526297 https://gist.github.com/nicowilliams/ea2fa2b445c2db50d2ee650...