4 ms·

> how do you split the contents of the staging area into two separate groups What is the workflow behind this ask? I don't understand what the goal is. The bas

> how do you split the contents of the staging area into two separate groups What is the workflow behind this ask? I don't understand what the goal is. The basic git workflow: 1. Edit and save a tracked file; the changes appear in the working tree. 2. Select some subset of the changes in the working tree to stage them in the index. 3. Form a commit with the changes in the index. IIUC you want to add a step in between 2 and 3? But the way I see it, 2 is doing what you want. I can split the set of current changes by selectively adding them to the index in preparation for a commit. I can also selectively un-stage changes if I decide I don't want them to become part of the commit. Between the changes to a file in whatever editor buffer I'm writing in, saving those to disk, moving changes from unstaged to staged, and forming a commit in any of a variety of ways (plain ol' commit, amending a commit, a fixup commit) I can't imagine what other way I need to slice and dice changes. Maybe it's just a failure of my imagination since I've been using Git for so long now and only more basic things like SVN/TFS/CVS before that.

arxanas 4y ago
To accomplish your workflow, there doesn't seem to be any need for a staging area at all. You can use an interactive commit selector to stage a subset of changes (or select a set of changes some other way), and then if you want to keep adding/"staging" changes, you can amend the commit you just made. Occasionally, I do run into the situation where I've staged some changes and then realize that I want to start staging another commit first, but don't want to lose the changed I already staged. Unstaging my current changes means I have to remember and select them again later. I could also just commit what I have staged and start staging a new commit (and perhaps reorder the commits later), but that shows that the staging area was unnecessary in the first place, and I could have used commits to accomplish the same workflow without adding a new set of concepts to my VCS.
- tome 4y ago
  > You can use an interactive commit selector ... such as `git commit --patch`, which this discussion has taught me many people don't know about, even those who know about `git add --patch`. (I was one such person a few years ago until my mind was blown by an HN commentor doing me the same favour as I have done here :) .)

arxanas 4y ago

To accomplish your workflow, there doesn't seem to be any need for a staging area at all. You can use an interactive commit selector to stage a subset of changes (or select a set of changes some other way), and then if you want to keep adding/"staging" changes, you can amend the commit you just made. Occasionally, I do run into the situation where I've staged some changes and then realize that I want to start staging another commit first, but don't want to lose the changed I already staged. Unstaging my current changes means I have to remember and select them again later. I could also just commit what I have staged and start staging a new commit (and perhaps reorder the commits later), but that shows that the staging area was unnecessary in the first place, and I could have used commits to accomplish the same workflow without adding a new set of concepts to my VCS.

tome 4y ago
> You can use an interactive commit selector ... such as `git commit --patch`, which this discussion has taught me many people don't know about, even those who know about `git add --patch`. (I was one such person a few years ago until my mind was blown by an HN commentor doing me the same favour as I have done here :) .)