4 ms·

I always use a soft reset when I accidentally commit in the wrong order, because I like keeping my history tidy. If the change is live, I always use revert. On

I always use a soft reset when I accidentally commit in the wrong order, because I like keeping my history tidy. If the change is live, I always use revert. On another note, I love how HN can go from complex research papers I struggle to keep up with, to explaining git commands the next day — something I learned within my first month of Git and never had a problem with again. How bipolar.

kazinator 8y ago
If you commit in the wrong order and want to set it straight, learn to use "git rebase -i" (i.e. --interactive) "git reset --patch" is useful for unraveling changes that were wrongly combined into a single commit.
- JshWright 8y ago
  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)
  - bb88 8y ago
    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.
    - black-tea 8y ago
      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.
  - kazinator 8y ago
    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.
    - deleted 8y ago
      [deleted]
- amingilani 8y ago
  I do already do! :) I use interactive rebase to squash multiple commits together when I need it. However, I just find it easier to start from scratch if I changed 4 files at once, wanted the changes spread out over 3 commits, and I did those in the wrong order or something.

kazinator 8y ago

If you commit in the wrong order and want to set it straight, learn to use "git rebase -i" (i.e. --interactive) "git reset --patch" is useful for unraveling changes that were wrongly combined into a single commit.

JshWright 8y ago
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)
- bb88 8y ago
  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.
  - black-tea 8y ago
    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.
- kazinator 8y ago
  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.
  - deleted 8y ago
    [deleted]
amingilani 8y ago
I do already do! :) I use interactive rebase to squash multiple commits together when I need it. However, I just find it easier to start from scratch if I changed 4 files at once, wanted the changes spread out over 3 commits, and I did those in the wrong order or something.