2 ms·
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 splitti
by 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 agoThat 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 agoI'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).