6 ms·

The one thing I wish were easier would be breaking a single commit into two commits. Edit: to be clear, I know it's possible by using git reset... but I'd much

The one thing I wish were easier would be breaking a single commit into two commits. Edit: to be clear, I know it's possible by using git reset... but I'd much rather have something like git add -i that interactively shifts changes from the commit itself and moves them into working directory-only changes.

dljsjr 5y ago
1. `git rebase -i` to the commit before the one you want to split 2. mark the commit you want to split as an `edit` 3. remove the file(s) you want to edit from the index so that it's part of your working tree 4. use `git add -p` to stage the hunks you want in the first commit (assuming you want to split commits in a single file) or just commit the files you want in the first commit first, second commit second.
- okl 5y ago
  > 4. use `git add -p` I strongly recommend tig
  - dljsjr 5y ago
    lazygit is also great. VS Code also makes it easy to stage hunks in the editor if you like to stay in your editor; in the diff viewer from the Git view you can highlight the lines you want to stage and right click -> stage selected ranges. I've never used tig. I'll look at it.
  - cerved 5y ago
    what's the advantage over partial?
    - okl 5y ago
      Give it a try and compare. tig lets you either stage hunks ('u') or lines ('1'). You can also adjust the context ('[', ']') and split chunks ('\') and revert chunks ('!') all from the same view.
      - cerved 5y ago
        I will thanks but I must say in mostly very happy with --partial, except stash which is slow, or when there are 20+ hunks
  - atq2119 5y ago
    +1 for tig, and for the folks that are less TUI-inclined, there's `git gui`; a neat little tool which is far too little known considering that it's part of core Git. One of the nice things about `git gui` is that it has an "amend last commit" mode that makes splitting up a commit trivial (unless the commit also adds or removes files -- in that case, you're going to have to do some more work).
okl 5y ago
Not much trouble if you're used to it. git rebase --interactive master In Vim: ciw e ESC :x git reset HEAD~ // Make your commits git rebase --continue

dljsjr 5y ago

1. `git rebase -i` to the commit before the one you want to split 2. mark the commit you want to split as an `edit` 3. remove the file(s) you want to edit from the index so that it's part of your working tree 4. use `git add -p` to stage the hunks you want in the first commit (assuming you want to split commits in a single file) or just commit the files you want in the first commit first, second commit second.

okl 5y ago
> 4. use `git add -p` I strongly recommend tig
- dljsjr 5y ago
  lazygit is also great. VS Code also makes it easy to stage hunks in the editor if you like to stay in your editor; in the diff viewer from the Git view you can highlight the lines you want to stage and right click -> stage selected ranges. I've never used tig. I'll look at it.
- cerved 5y ago
  what's the advantage over partial?
  - okl 5y ago
    Give it a try and compare. tig lets you either stage hunks ('u') or lines ('1'). You can also adjust the context ('[', ']') and split chunks ('\') and revert chunks ('!') all from the same view.
    - cerved 5y ago
      I will thanks but I must say in mostly very happy with --partial, except stash which is slow, or when there are 20+ hunks
- atq2119 5y ago
  +1 for tig, and for the folks that are less TUI-inclined, there's `git gui`; a neat little tool which is far too little known considering that it's part of core Git. One of the nice things about `git gui` is that it has an "amend last commit" mode that makes splitting up a commit trivial (unless the commit also adds or removes files -- in that case, you're going to have to do some more work).

okl 5y ago

Not much trouble if you're used to it. git rebase --interactive master In Vim: ciw e ESC :x git reset HEAD~ // Make your commits git rebase --continue