4 ms·

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

> 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...
- martinvonz 5y ago
  That gist seems like a simplified version of https://github.com/mhagger/git-imerge https://github.com/mhagger/git-imerge, so check that out if you haven't. (I haven't looked at git-imerge in a long time, so I should read about it again myself.)
  - cryptonector 5y ago
    I'll take a look, thanks for the link! EDIT: The idea of being able to suspend/resume and push/fetch in-progress merges/rebases is very cool indeed. It's hard to tell if it could speed up the task of rebasing across thousands of commits or not -- the README doesn't say. I like Viktor's script because it's very focused on one thing: quickly rebasing local commits across thousands of new upstream commits with a minimum of conflicts -- a simple solution to a simple problem statement (though the problem can feel huge when you have it).

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

martinvonz 5y ago
That gist seems like a simplified version of https://github.com/mhagger/git-imerge https://github.com/mhagger/git-imerge, so check that out if you haven't. (I haven't looked at git-imerge in a long time, so I should read about it again myself.)
- cryptonector 5y ago
  I'll take a look, thanks for the link! EDIT: The idea of being able to suspend/resume and push/fetch in-progress merges/rebases is very cool indeed. It's hard to tell if it could speed up the task of rebasing across thousands of commits or not -- the README doesn't say. I like Viktor's script because it's very focused on one thing: quickly rebasing local commits across thousands of new upstream commits with a minimum of conflicts -- a simple solution to a simple problem statement (though the problem can feel huge when you have it).