5 ms·

The only problem I have with this workflow in the command line is that I would like to be able to split changes to the same file across multiple commits. I thi

The only problem I have with this workflow in the command line is that I would like to be able to split changes to the same file across multiple commits. I think some GUI tools enable this, anyone know about it?

arilotter 5y ago
When you're doing your interactive rebase, find the commit you'd like to split - choose "edit" for that one. Then when you reach that point, you can do `git reset HEAD^1` to bring those changes back onto your staging stack, and make as many commits as you need.
tuckerpo 5y ago
I do this via git add -p which breaks your changeset down into atomic patches that you can either add, skip or delete before making a commit. You can turn one file change into many commits this way, if need be.
btschaegg 5y ago
Have a look at `tig`. It's even included in Git for Windows now and does this reasonably well. Only the keybindings are a bit weird if you're not accustomed to Vim bindings: - Open tig - Change into the staging view with `s` - Select your file using the arrow or `j` and `k` keys - Press Return to show the diff - Navigate to the line(s) in question with `j` and `k` (arrow keys will switch files) - Stage parts with `1` (single line), `2` (chunk parts), `u` (chunks) or split chunks with `\` - "Leave" the diff with `q` - You can find the keybindings with `h` in the help screen, which also uses Vim keys -- like manpages usually do
- mariusor 5y ago
  "s" is status view, which you can also get at by running "tig status" directly. "c" is staging view. > - Stage parts with `1` (single line), `2` (chunk parts), `u` (chunks) or split chunks with `\` You can also revert a chunk or file by using "!". Sometimes this is very useful.
  - btschaegg 5y ago
    Ah, thanks for the correction :)
- mikewhy 5y ago
  I used tig for a bit because it was the nicest way I could find to do line-level staging in a terminal. But was really impressed with gitui https://github.com/extrawurst/gitui https://github.com/extrawurst/gitui so I've switched to that
yodsanklai 5y ago
The way I deal with this is 1. try to make commits small enough so you are less likely to split them after the fact. 2. when I need to split a commit, I use VSCode UI and apply patch by patch. This is one of the rare case were I use a GUI for git. For most other things the command line is fine.
bentcorner 5y ago
sublime merge handles this really nicely. You can do this in VS code too but the UI is a little more fiddly (right-click->"Stage Selected Range").
matijsvzuijlen 5y ago
Git has a built-in GUI for that. Just run 'git gui'. It's not pretty but it works.
- simlevesque 5y ago
  > git gui git: 'gui' is not a git command. See 'git --help'. The most similar commands are gc grep init pull push
  - formerly_proven 5y ago
    It's a separate package in some distros since it's written in Perl and uses Tk. gitk is often in the same package.
    - bmn__ 5y ago
      Both git-gui and gitk are in Tcl, not Perl.
atq2119 5y ago
I can second the recommendation of tig in the sibling comment. Additionally, git itself comes with a simple `git gui` command that allows you to do partial commits on a line by line basis. It also has a nice "amend last commit" mode.
distortedsignal 5y ago
I use the interactive flag on git add for this. It lets you add parts of a file, commit, and then do it all again. I want to say it's git add -i, but I'm not 100% on that. My fingers just do the right thing when I want it to happen.
- Izkata 5y ago
  It's "p" for "partial"
kjeetgill 5y ago
If you're a vim guy, I use `git difftool` setup with `vimdiff` for this. Let's say you have your changes in a branch CHANGES on top of public branch PUBLIC. 1. I `git checkout PUBLIC -b CLEANUP` to a new branch. 2. Do a `git difftool CHANGES`, which opens each changed file in vimdiff one at a time. 3. For each file, I use :diffput/:diffget or just edit in changes I want. 4. Commit these changes on the CLEANUP branch. 5. Use `git difftool CHANGES` again to see the remaining diff. 6. Repeat until the diff comes back empty! My unstructured changes tend to contain a handful of small typo fixes, white spacing, localized refactors, and 1 or 2 larger refactors and a behavioral change. Once they're all broken out, It's usually easy enough to use `git rebase -i` and reorder the smaller changes first, put out PRs for just those first, etc.
newaccount74 5y ago
If you have a Mac, check out GitUp. It's a simple but fantastic tool for cleaning up git histories: merging commits, splitting commits, reordering...
erdo 5y ago
Gitx is great for that on a mac, but every time I set up a new MacBook I have to hunt down the latest repo / build. It keeps getting abandoned and then forked and continued, and then abandoned again... Edit: looks like it's back from the dead again :) https://github.com/gitx/gitx https://github.com/gitx/gitx
tailspin2019 5y ago
I use Sourcetree [0] for this (on Mac but Win version available) I've tried most Git clients on Mac over the years and kept gravitating back to Sourcetree. I only tend to use it for this particular workflow (picking out very granular changes on a line-by-line basis). Otherwise, 90% of my git stuff is via IDE integrations or command line. [0] https://www.sourcetreeapp.com https://www.sourcetreeapp.com

arilotter 5y ago

When you're doing your interactive rebase, find the commit you'd like to split - choose "edit" for that one. Then when you reach that point, you can do `git reset HEAD^1` to bring those changes back onto your staging stack, and make as many commits as you need.

tuckerpo 5y ago

I do this via git add -p which breaks your changeset down into atomic patches that you can either add, skip or delete before making a commit. You can turn one file change into many commits this way, if need be.

btschaegg 5y ago

Have a look at `tig`. It's even included in Git for Windows now and does this reasonably well. Only the keybindings are a bit weird if you're not accustomed to Vim bindings: - Open tig - Change into the staging view with `s` - Select your file using the arrow or `j` and `k` keys - Press Return to show the diff - Navigate to the line(s) in question with `j` and `k` (arrow keys will switch files) - Stage parts with `1` (single line), `2` (chunk parts), `u` (chunks) or split chunks with `\` - "Leave" the diff with `q` - You can find the keybindings with `h` in the help screen, which also uses Vim keys -- like manpages usually do

mariusor 5y ago
"s" is status view, which you can also get at by running "tig status" directly. "c" is staging view. > - Stage parts with `1` (single line), `2` (chunk parts), `u` (chunks) or split chunks with `\` You can also revert a chunk or file by using "!". Sometimes this is very useful.
- btschaegg 5y ago
  Ah, thanks for the correction :)
mikewhy 5y ago
I used tig for a bit because it was the nicest way I could find to do line-level staging in a terminal. But was really impressed with gitui https://github.com/extrawurst/gitui https://github.com/extrawurst/gitui so I've switched to that

yodsanklai 5y ago

The way I deal with this is 1. try to make commits small enough so you are less likely to split them after the fact. 2. when I need to split a commit, I use VSCode UI and apply patch by patch. This is one of the rare case were I use a GUI for git. For most other things the command line is fine.

bentcorner 5y ago

sublime merge handles this really nicely. You can do this in VS code too but the UI is a little more fiddly (right-click->"Stage Selected Range").

matijsvzuijlen 5y ago

Git has a built-in GUI for that. Just run 'git gui'. It's not pretty but it works.

simlevesque 5y ago
> git gui git: 'gui' is not a git command. See 'git --help'. The most similar commands are gc grep init pull push
- formerly_proven 5y ago
  It's a separate package in some distros since it's written in Perl and uses Tk. gitk is often in the same package.
  - bmn__ 5y ago
    Both git-gui and gitk are in Tcl, not Perl.

atq2119 5y ago

I can second the recommendation of tig in the sibling comment. Additionally, git itself comes with a simple `git gui` command that allows you to do partial commits on a line by line basis. It also has a nice "amend last commit" mode.

distortedsignal 5y ago

I use the interactive flag on git add for this. It lets you add parts of a file, commit, and then do it all again. I want to say it's git add -i, but I'm not 100% on that. My fingers just do the right thing when I want it to happen.

Izkata 5y ago
It's "p" for "partial"

kjeetgill 5y ago

If you're a vim guy, I use `git difftool` setup with `vimdiff` for this. Let's say you have your changes in a branch CHANGES on top of public branch PUBLIC. 1. I `git checkout PUBLIC -b CLEANUP` to a new branch. 2. Do a `git difftool CHANGES`, which opens each changed file in vimdiff one at a time. 3. For each file, I use :diffput/:diffget or just edit in changes I want. 4. Commit these changes on the CLEANUP branch. 5. Use `git difftool CHANGES` again to see the remaining diff. 6. Repeat until the diff comes back empty! My unstructured changes tend to contain a handful of small typo fixes, white spacing, localized refactors, and 1 or 2 larger refactors and a behavioral change. Once they're all broken out, It's usually easy enough to use `git rebase -i` and reorder the smaller changes first, put out PRs for just those first, etc.

newaccount74 5y ago

If you have a Mac, check out GitUp. It's a simple but fantastic tool for cleaning up git histories: merging commits, splitting commits, reordering...

erdo 5y ago

Gitx is great for that on a mac, but every time I set up a new MacBook I have to hunt down the latest repo / build. It keeps getting abandoned and then forked and continued, and then abandoned again... Edit: looks like it's back from the dead again :) https://github.com/gitx/gitx https://github.com/gitx/gitx

tailspin2019 5y ago

I use Sourcetree [0] for this (on Mac but Win version available) I've tried most Git clients on Mac over the years and kept gravitating back to Sourcetree. I only tend to use it for this particular workflow (picking out very granular changes on a line-by-line basis). Otherwise, 90% of my git stuff is via IDE integrations or command line. [0] https://www.sourcetreeapp.com https://www.sourcetreeapp.com