6 ms·

Show HN: `Git add -p` with multiple buckets

94 points by aleclm 5y ago

jayd16 5y ago
This is the one P4 workflow feature I wish git had from the beginning. In Perforce, changes can be grouped into uncommitted "change lists." Its really helpful if you're working on multiple things especially when they're unrelated features or projects. Works very well for artists and such. Sadly P4 fumbles at the 10 because you can't split changes by hunk, file only. I hope something like this (or maybe just multiple named stages?) makes it into git.
- RyJones 5y ago
  Are you ex-MSFT? I am, and I miss that workflow.
- noitpmeder 5y ago
  My company still uses p4 for most things and most developers I know HATE it, compared to the equivalent git(hub/lab). Largest complaints currently are the infesibility of the feature-branch workflow and the terribad pre-commit code review story.
  - jayd16 5y ago
    I much prefer git and the git ecosystem but a good feature is a good feature
- vbezhenar 5y ago
  Idea can do that with git.
pabs3 5y ago
I generally just use `git gui` to make multiple commits by staging and then committing just the lines I want.
- spartanatreyu 5y ago
  I'm pretty sure git got rid of their `git gui` command a while ago. What version of git are you using? You probably want to check with `git --version`. The latest version is 2.35.1.
  - pabs3 5y ago
    I'm using 2.35.1, perhaps you haven't installed the git-gui and gitk packages for your distro? Both git gui and gitk are still in the git repo AFAICT: https://github.com/git/git/tree/master/git-gui https://github.com/git/git/tree/master/git-gui https://github.com/git/git/tree/master/gitk-git https://github.com/git/git/tree/master/gitk-git
westurner 5y ago
There are probably a couple good ways to avoid trying to split `git add -p` with e.g. jujutsu `jj`? https://github.com/martinvonz/jj/blob/main/docs/git-comparison.md https://github.com/martinvonz/jj/blob/main/docs/git-comparis... If CI isn't running tests for every PR, `git add -p` can create pretty patches that fail when attempting to `git bisect` later. > Comprehensive support for rewriting history: Besides the usual rebase command, there's `jj describe` for editing the description (commit message) of an arbitrary commit. There's also `jj edit`, which lets you edit the changes in a commit without checking it out. To split a commit into two, use `jj split`. You can even move part of the changes in a commit to any other commit using `jj move`.
u801e 5y ago
There's a set of utilities[1] in a package called patchutils that contains several commands to manipulate patches. Their version of splitdiff[2] will create a set of patch files from a single patch where each patch would only apply to a single file. It doesn't appear to have the capability of splitting out individual hunks like your version, but could be updated to do so. [1] https://directory.fsf.org/wiki/Patchutils https://directory.fsf.org/wiki/Patchutils [2] https://www.unix.com/man-page/suse/1/splitdiff/ https://www.unix.com/man-page/suse/1/splitdiff/
mushyhammer 5y ago
I find it crazy how many people like working with git from the command line and just use -a any chance they get. I never commit from CLI and have been using GitHub Desktop for years (it works on any repo/remote). Selecting individual files, patches, or even lines is a breeze. I usually make a bunch of changes, then pick, commit, branch, repeat. Every branch is based off `main` and can be pushed independently. Any leftover will just be dropped (any logging/testing lines that I never picked, for example) Using a UI makes it easy to review your changes before you commit them, there’s no way you can review (and pick or discard) your 100-lines 5-files changes effectively on the command line. GitHub Desktop is quite limited and I hope it stays that way, I still use the cli for operations other than commit and checkout.
- u801e 5y ago
  I actually use the git cli by filtering text to various command std input using vim. So, for staging diffs, I'll read the output of git diff, and hand edit the diff as needed, and stage individual hunks by filtering the text through the git apply command with the appropriate parameters. I can then run git status -v to show what's currently staged, write the commit message and filter it through the git commit command. > there’s no way you can review (and pick or discard) your 100-lines 5-files changes effectively on the command line. It's easy enough to find the approriate hunk and edit the diff to stage what's needed. I may go through the process a few times to create a single commit depending on how many hunks I have to deal with and how many times I need to split them though. In fact, my normal workflow is to make the necessary changes for a particular feature I'm working on, take the diff against the base branch and then stage parts of that diff to create a series of sensible commits for the branch.
  - 1MachineElf 5y ago
    I would really like to see this workflow. Are there any articles, videos, or asciinemia recordings of how this is done?
    - u801e 5y ago
      I don't know of any, but the key thing to know is how to edit diffs manually. If you've ever run git add or reset with the -p parameter, you may have noticed an option where you can manually edit a diff hunk. If you choose that option, it describes several rules for editing hunks: 1. Remove lines beginning with + to keep them from being added 2. Replace the beginning - with <space> for lines to keep them from being removed But you can go further with this by adding more lines beginning with + to add lines that weren't in the original hunk, or add a - prefix to a context line (beginning with a <space>) to remove it. You can even modify the content of lines prefixed with + (i.e., to fix a syntax error you noticed) before staging them. The other thing to note is the surrounding context lines for a given hunk. Ideally, you have at least 3 lines before and 3 lines after the hunk to ensure that when it's applied, it changes the file in the correct location. In order to actually stage a hunk, you need to add the necessary header lines above the line that begins with @@. These lines are the ones that begin with diff, index, ---, and +++. For the first, third and fourth lines, the path and file name need to match the file you intend to apply the patch to. When you're ready to stage your edited hunk, you just visually highlight it in vim (shift-v) and then run :'<,'> !git apply --cached --recount The --cached option prevents git from trying to modify the file in the working tree and limits it to just modifying what's in the git index. The --recount option basially makes it easier to apply an edited patch by not really looking at the line that begins with @@. If your patch applies, you can view how it looks like in the index by running git status -v or git diff --cached You can even view the file as it is in the git index by running git show :0:path/to/file
junon 5y ago
I wish git supported this directly. Even if it was specific functionality to `git commit -p`.
ArtRichards 5y ago
I was looking a few years ago for a GUI for git, on linux. I eventually settled on SmartGit, been using it since.. https://www.syntevo.com/smartgit/ https://www.syntevo.com/smartgit/ Anyone have alternatives for Linux?
- davvid 5y ago
  http://git-cola.github.io/ http://git-cola.github.io/ has all of the nice split-patch index editing stuff (and much more) and is vimmish in its keyboard interactions.
- efficientsticks 5y ago
  I haven’t used it in years, but magit is really great. Nowadays I just do a few rounds of git add -p; commit, or trusty ole git commit -av
kasabali 5y ago
See also Mercurial Queues (https://www.mercurial-scm.org/wiki/MqExtension https://www.mercurial-scm.org/wiki/MqExtension)
renewiltord 5y ago
Oh this is interesting. Sometimes I make unrelated changes and then I want to tease the things apart at commit time. And when I do I find that I don’t just want to stage or skip staging. Worth a shot but I’d prefer if I could put it into secondary staging and post-commit the first of those becomes staged. Probably doable and shiftable to a git-splitpatch too.
- chx 5y ago
  perhaps as branches? then we can cherry pick those as needed.
  - OJFord 5y ago
    Stashes are more appropriate; since they're really just handier references to commits they can be cherry-picked too, as `stash@{N}` where N is the zero-based integer for which one you want. (You can even `git cherry-pick stash@{0}^` for the commit the stash was made at. It really is just a commit made at that point, with that parent, only without updating HEAD, or the checked-out branch.)
    - chx 5y ago
      Thanks for reminding me, I have used arbitrarily named refs before just slipped my mind. So it could be like 'refs/patches' or whatever. I used refs/backups in my safety net https://gist.github.com/chx/3a694c2a077451e3d446f85546bb9278 https://gist.github.com/chx/3a694c2a077451e3d446f85546bb9278
- Sharlin 5y ago
  In modern gits you can also `git stash -p` allowing you to use (named if needed) stashes for that purpose.
  - aleclm 5y ago
    This is different. The key value of `split-patch` is that you can create as many patches (commits) as you want by doing a single pass over the (potentially large) patchset. If you're willing to do multiple passes over the patchset, you could `git commit` right away. Anyway, cool, I didn't know you could name stashes!
abalaji 5y ago
This is great, I've been using Sublime Merge similarly in my workflow. I stage individual files while drafting the commit message and make sure to split lines across commits for logical rollbacks. I personally find it a lot faster than using the CLI, at least in this case.
- warmwaffles 5y ago
  I specifically love committing individual lines in a hunk and leaving the rest not staged until I am good and ready to stage them. It's been a great addition to my workflow and makes self reviewing my stuff easier before I go to send a PR.
- barbazoo 5y ago
  I agree. For this workflow using a GUI to stage individual lines is just a lot faster.
  - hultner 5y ago
    Same here, I’m a tmux junkie but for the particular use case of staging smaller parts I much prefer sublime. Have been meaning to give fugitive a proper try as well, looks like it’a gui allows for a similar use case as well without the context switch.
dorianmariefr 5y ago
I feel like this should be part of git, also naming it git-split-patch and having it in the PATH would allow to to do `git split-patch`
- pabs3 5y ago
  It is useful outside of git, so I would suggest having both the git alias and the main command.
- aleclm 5y ago
  Yeah, that's what I want to do next.
  - pabs3 5y ago
    Please keep the main command too, since it is useful outside of git too, like when using the quilt patch system, or other VCSen like Mercurial.
fuzzy2 5y ago
Ah, finally changelists are coming to Git. Having worked with Perforce, this certainly feels very familiar.
- charcircuit 5y ago
  This is unrelated to git. What do you mean by change list?
  - fuzzy2 5y ago
    Dunno what you mean by this being unrelated to Git. In Git, you can stage files (git add). You have only one “staging area”. In Perforce, you can also stage files (of sorts). You can create as many “staging areas” (changelists) as you want. Changelists are publicly visible, if so desired, before they are even “committed” (submitted, in P4 jargon). Changelists work on entire files, unlike what TFA proposes.
    - charcircuit 5y ago
      >Dunno what you mean by this being unrelated to Git. This tool is for splitting patches. It's a tool for working with patches and not one for working with git. Now of course patches are used with git.
alfiedotwtf 5y ago
Oh very nice! This almost seems obvious that it should be part of git itself!
almog 5y ago
Is the main use case being splitting large uncommitted change set into logical units in _one pass_ rather than few iterations of `git add -p && git commit`?
- bckr 5y ago
  this is my question as well
- teaearlgraycold 5y ago
  That would be helpful for me. Sometimes I forget which pass I'm on and have to redo the commit.
  - almog 5y ago
    I don't do this often, but when I watched the demo that was the only use case that came to mind. Perhaps the author had different motivation to start it, which is why I posted this question — the demo explain what the program does but provide little context other than extracting actual patches, and then again, it begs the question of 'why'.
- aleclm 5y ago
  That's exactly the use case.
  - almog 5y ago
    Cool, I thought there might be some other flow I was not aware of, thanks for clarifying that! The demo recording is good and I think it would be even better to state the motivation/use case explicitly in the README.

94 points by aleclm 5y ago

This is the one P4 workflow feature I wish git had from the beginning. In Perforce, changes can be grouped into uncommitted "change lists." Its really helpful if you're working on multiple things especially when they're unrelated features or projects. Works very well for artists and such. Sadly P4 fumbles at the 10 because you can't split changes by hunk, file only. I hope something like this (or maybe just multiple named stages?) makes it into git.

RyJones 5y ago
Are you ex-MSFT? I am, and I miss that workflow.
noitpmeder 5y ago
My company still uses p4 for most things and most developers I know HATE it, compared to the equivalent git(hub/lab). Largest complaints currently are the infesibility of the feature-branch workflow and the terribad pre-commit code review story.
- jayd16 5y ago
  I much prefer git and the git ecosystem but a good feature is a good feature
vbezhenar 5y ago
Idea can do that with git.

pabs3 5y ago

I generally just use `git gui` to make multiple commits by staging and then committing just the lines I want.

spartanatreyu 5y ago
I'm pretty sure git got rid of their `git gui` command a while ago. What version of git are you using? You probably want to check with `git --version`. The latest version is 2.35.1.
- pabs3 5y ago
  I'm using 2.35.1, perhaps you haven't installed the git-gui and gitk packages for your distro? Both git gui and gitk are still in the git repo AFAICT: https://github.com/git/git/tree/master/git-gui https://github.com/git/git/tree/master/git-gui https://github.com/git/git/tree/master/gitk-git https://github.com/git/git/tree/master/gitk-git

westurner 5y ago

There are probably a couple good ways to avoid trying to split `git add -p` with e.g. jujutsu `jj`? https://github.com/martinvonz/jj/blob/main/docs/git-comparison.md https://github.com/martinvonz/jj/blob/main/docs/git-comparis... If CI isn't running tests for every PR, `git add -p` can create pretty patches that fail when attempting to `git bisect` later. > Comprehensive support for rewriting history: Besides the usual rebase command, there's `jj describe` for editing the description (commit message) of an arbitrary commit. There's also `jj edit`, which lets you edit the changes in a commit without checking it out. To split a commit into two, use `jj split`. You can even move part of the changes in a commit to any other commit using `jj move`.

u801e 5y ago

There's a set of utilities[1] in a package called patchutils that contains several commands to manipulate patches. Their version of splitdiff[2] will create a set of patch files from a single patch where each patch would only apply to a single file. It doesn't appear to have the capability of splitting out individual hunks like your version, but could be updated to do so. [1] https://directory.fsf.org/wiki/Patchutils https://directory.fsf.org/wiki/Patchutils [2] https://www.unix.com/man-page/suse/1/splitdiff/ https://www.unix.com/man-page/suse/1/splitdiff/

mushyhammer 5y ago

I find it crazy how many people like working with git from the command line and just use -a any chance they get. I never commit from CLI and have been using GitHub Desktop for years (it works on any repo/remote). Selecting individual files, patches, or even lines is a breeze. I usually make a bunch of changes, then pick, commit, branch, repeat. Every branch is based off `main` and can be pushed independently. Any leftover will just be dropped (any logging/testing lines that I never picked, for example) Using a UI makes it easy to review your changes before you commit them, there’s no way you can review (and pick or discard) your 100-lines 5-files changes effectively on the command line. GitHub Desktop is quite limited and I hope it stays that way, I still use the cli for operations other than commit and checkout.

u801e 5y ago
I actually use the git cli by filtering text to various command std input using vim. So, for staging diffs, I'll read the output of git diff, and hand edit the diff as needed, and stage individual hunks by filtering the text through the git apply command with the appropriate parameters. I can then run git status -v to show what's currently staged, write the commit message and filter it through the git commit command. > there’s no way you can review (and pick or discard) your 100-lines 5-files changes effectively on the command line. It's easy enough to find the approriate hunk and edit the diff to stage what's needed. I may go through the process a few times to create a single commit depending on how many hunks I have to deal with and how many times I need to split them though. In fact, my normal workflow is to make the necessary changes for a particular feature I'm working on, take the diff against the base branch and then stage parts of that diff to create a series of sensible commits for the branch.
- 1MachineElf 5y ago
  I would really like to see this workflow. Are there any articles, videos, or asciinemia recordings of how this is done?
  - u801e 5y ago
    I don't know of any, but the key thing to know is how to edit diffs manually. If you've ever run git add or reset with the -p parameter, you may have noticed an option where you can manually edit a diff hunk. If you choose that option, it describes several rules for editing hunks: 1. Remove lines beginning with + to keep them from being added 2. Replace the beginning - with <space> for lines to keep them from being removed But you can go further with this by adding more lines beginning with + to add lines that weren't in the original hunk, or add a - prefix to a context line (beginning with a <space>) to remove it. You can even modify the content of lines prefixed with + (i.e., to fix a syntax error you noticed) before staging them. The other thing to note is the surrounding context lines for a given hunk. Ideally, you have at least 3 lines before and 3 lines after the hunk to ensure that when it's applied, it changes the file in the correct location. In order to actually stage a hunk, you need to add the necessary header lines above the line that begins with @@. These lines are the ones that begin with diff, index, ---, and +++. For the first, third and fourth lines, the path and file name need to match the file you intend to apply the patch to. When you're ready to stage your edited hunk, you just visually highlight it in vim (shift-v) and then run :'<,'> !git apply --cached --recount The --cached option prevents git from trying to modify the file in the working tree and limits it to just modifying what's in the git index. The --recount option basially makes it easier to apply an edited patch by not really looking at the line that begins with @@. If your patch applies, you can view how it looks like in the index by running git status -v or git diff --cached You can even view the file as it is in the git index by running git show :0:path/to/file

junon 5y ago

I wish git supported this directly. Even if it was specific functionality to `git commit -p`.

ArtRichards 5y ago

I was looking a few years ago for a GUI for git, on linux. I eventually settled on SmartGit, been using it since.. https://www.syntevo.com/smartgit/ https://www.syntevo.com/smartgit/ Anyone have alternatives for Linux?

davvid 5y ago
http://git-cola.github.io/ http://git-cola.github.io/ has all of the nice split-patch index editing stuff (and much more) and is vimmish in its keyboard interactions.
efficientsticks 5y ago
I haven’t used it in years, but magit is really great. Nowadays I just do a few rounds of git add -p; commit, or trusty ole git commit -av

kasabali 5y ago

See also Mercurial Queues (https://www.mercurial-scm.org/wiki/MqExtension https://www.mercurial-scm.org/wiki/MqExtension)

renewiltord 5y ago

Oh this is interesting. Sometimes I make unrelated changes and then I want to tease the things apart at commit time. And when I do I find that I don’t just want to stage or skip staging. Worth a shot but I’d prefer if I could put it into secondary staging and post-commit the first of those becomes staged. Probably doable and shiftable to a git-splitpatch too.

chx 5y ago
perhaps as branches? then we can cherry pick those as needed.
- OJFord 5y ago
  Stashes are more appropriate; since they're really just handier references to commits they can be cherry-picked too, as `stash@{N}` where N is the zero-based integer for which one you want. (You can even `git cherry-pick stash@{0}^` for the commit the stash was made at. It really is just a commit made at that point, with that parent, only without updating HEAD, or the checked-out branch.)
  - chx 5y ago
    Thanks for reminding me, I have used arbitrarily named refs before just slipped my mind. So it could be like 'refs/patches' or whatever. I used refs/backups in my safety net https://gist.github.com/chx/3a694c2a077451e3d446f85546bb9278 https://gist.github.com/chx/3a694c2a077451e3d446f85546bb9278
Sharlin 5y ago
In modern gits you can also `git stash -p` allowing you to use (named if needed) stashes for that purpose.
- aleclm 5y ago
  This is different. The key value of `split-patch` is that you can create as many patches (commits) as you want by doing a single pass over the (potentially large) patchset. If you're willing to do multiple passes over the patchset, you could `git commit` right away. Anyway, cool, I didn't know you could name stashes!

abalaji 5y ago

This is great, I've been using Sublime Merge similarly in my workflow. I stage individual files while drafting the commit message and make sure to split lines across commits for logical rollbacks. I personally find it a lot faster than using the CLI, at least in this case.

warmwaffles 5y ago
I specifically love committing individual lines in a hunk and leaving the rest not staged until I am good and ready to stage them. It's been a great addition to my workflow and makes self reviewing my stuff easier before I go to send a PR.
barbazoo 5y ago
I agree. For this workflow using a GUI to stage individual lines is just a lot faster.
- hultner 5y ago
  Same here, I’m a tmux junkie but for the particular use case of staging smaller parts I much prefer sublime. Have been meaning to give fugitive a proper try as well, looks like it’a gui allows for a similar use case as well without the context switch.

dorianmariefr 5y ago

I feel like this should be part of git, also naming it git-split-patch and having it in the PATH would allow to to do `git split-patch`

pabs3 5y ago
It is useful outside of git, so I would suggest having both the git alias and the main command.
aleclm 5y ago
Yeah, that's what I want to do next.
- pabs3 5y ago
  Please keep the main command too, since it is useful outside of git too, like when using the quilt patch system, or other VCSen like Mercurial.

fuzzy2 5y ago

Ah, finally changelists are coming to Git. Having worked with Perforce, this certainly feels very familiar.

charcircuit 5y ago
This is unrelated to git. What do you mean by change list?
- fuzzy2 5y ago
  Dunno what you mean by this being unrelated to Git. In Git, you can stage files (git add). You have only one “staging area”. In Perforce, you can also stage files (of sorts). You can create as many “staging areas” (changelists) as you want. Changelists are publicly visible, if so desired, before they are even “committed” (submitted, in P4 jargon). Changelists work on entire files, unlike what TFA proposes.
  - charcircuit 5y ago
    >Dunno what you mean by this being unrelated to Git. This tool is for splitting patches. It's a tool for working with patches and not one for working with git. Now of course patches are used with git.

alfiedotwtf 5y ago

Oh very nice! This almost seems obvious that it should be part of git itself!

almog 5y ago

Is the main use case being splitting large uncommitted change set into logical units in _one pass_ rather than few iterations of `git add -p && git commit`?

bckr 5y ago
this is my question as well
teaearlgraycold 5y ago
That would be helpful for me. Sometimes I forget which pass I'm on and have to redo the commit.
- almog 5y ago
  I don't do this often, but when I watched the demo that was the only use case that came to mind. Perhaps the author had different motivation to start it, which is why I posted this question — the demo explain what the program does but provide little context other than extracting actual patches, and then again, it begs the question of 'why'.
aleclm 5y ago
That's exactly the use case.
- almog 5y ago
  Cool, I thought there might be some other flow I was not aware of, thanks for clarifying that! The demo recording is good and I think it would be even better to state the motivation/use case explicitly in the README.