News for hackers. Stuff that matters.
Re:Git reset vs. Git revert by JshWright on Monday February 04, 2019 @10:09PM (#19082764)
Interactive rebasing works fine for teasing apart commits as well (maybe slightly clumsier, but c'mon... it's git, it's _supposed_ to be a frustrating UX)
Re:Git reset vs. Git revert by bb88 on Monday February 04, 2019 @10:22PM (#19082812)
Yes... it is, until you realize it's a command line manipulation of a data structure.

Rebase, branching, diff, cherry pick, merging is just manipulating a DAG.

When you're on your own branch it's often easier to think of it as a linked list.

Re:Git reset vs. Git revert by black-tea on Tuesday February 05, 2019 @03:02AM (#19083676)
Even if you're on your own branch you can easily get a DAG after rebasing or resetting. The reflog keeps track of the history of all refs (ie. branch names) that you change. After you rebase your old commits are still there! It's actually quite hard to remove commits.

Trusting the reflog is key to becoming good at git.

Re:Git reset vs. Git revert by kazinator on Monday February 04, 2019 @10:43PM (#19082874)
How do you do that?

I use interactive rebasing as the backdrop for teasing apart commits that are not the HEAD commit; it provides the navigation through the commits.

The cherry-pick operations that underpin rebase are not what actually does the teasing-apart, though; I do that with with git reset --interactive HEAD^ when I've landed using "edit" on the commit I want to separate.