5 ms·

Same here. Without staging how do I change 10 files but only commit 3 of them? For example working on a change, then notice a bug that should be fixed now. Curr

Same here. Without staging how do I change 10 files but only commit 3 of them? For example working on a change, then notice a bug that should be fixed now. Currently I just stage the 3 files for the hot bug fix, commit those, deploy, then continue working on the remaining 7 files.

ufo 8y ago
It is possible to use git stash for that. In addition to being conceptually simpler it also allows you to run tests on the “partial commit” before commiting it.
- GuiA 8y ago
  git stash actually changes what's on the filesystem though (i.e. you cannot randomly open up something that is stashed in an arbitrary text editor).
  - ufo 8y ago
    You could always just unstash things, I suppose. In the context I was talking about, the stash is only used to prepare a commit, and after that you can unstash everything. For longer term stashing I think named branches you easily checkout are a better alternative.
- chrisweekly 8y ago
  +1 for git stash -- but I don't like the idea of eliminating the staging area.
ori_b 8y ago
Do the same as vanilla git: git commit those three files That operation is still not implemented in git/fs, but it's planned.
war1025 8y ago
I wonder how much overlap there is between the "staging area is useless" and the "never rewrite history" crowds. Personally, I use staging area all the time to create a curated set of commits that make logical sense when putting them up for review. My workflow is generally to keep a very messy history of `XXX` commits until I am happy with what I've come up with. Then reset back to the branch point and using the staging area to build up logical changesets. I don't care about the history of my coming up with the solution, I care about presenting the solution in a way that makes sense to reviewers, including future me.
- ori_b 8y ago
  Interesting, so you commit things that are different from the code that is sitting in your working directory at the time of the commit?
  - war1025 8y ago
    I use `git add -p` to selectively pick out chunks of code that fit together into commits. Later on, if I notice that I messed something up, I'll create a fixup commit and do an interactive rebase to squash it back into the correct commit.
    - e3b0c 8y ago
      In my opinion, `git add -p` should be the default, and a `-a` or alike to forcibly commit the entire working tree. I have developed a habit that I wouldn't feel comfortable if I haven't reviewed the chunks I am going to make into the commit.
      - erik_seaberg 8y ago
        Whereas I don't feel comfortable with untested work, so "git checkout -p" (undo a change) and "git stash -p" (postpone a change) are how I get the workspace clean enough to commit.
      - Rychard 8y ago
jcranmer 8y ago
Have a commit command line that lists only the three files in question. It's really not that hard. If you're going to suggest more complex scenarios, the answer usually boils down to in practice "you want an interactive commit anyways," with perhaps some form of (unpushed) history rewriting to move patch hunks around between different commits. The staging area is basically a half-baked, special commit that is easy to do manipulation on but hard to figure out what its actual state is (e.g., show me only the diffs that are in the staging area, or let me figure out what the hell is actually going on if I'm doing a complicated rebase). You know what would be better? Turn the staging area into a full, real commit and lower the friction of editing unpushed history to make it easy to move patch hunks in, out, and between these commits. It would help people who want commits to be atomic and therefore break WIP changes into multiple commits before publishing them for review.
- war1025 8y ago
  `git diff --cached` shows what is in the staging area
  - slavik81 8y ago
    There's an alias, `git diff --staged`, that I find a little easier to remember.
- deathanatos 8y ago
  > Have a commit command line that lists only the three files in question. It's really not that hard. And how would you stage & commit only a portion of the changes made to a file? (Like the parents, I use the staging area daily, and I am quite thankful for its existence.)
  - ori_b 8y ago
    > And how would you stage & commit only a portion of the changes made to a file? I wouldn't. That code is untested, and I have a thing against committing untested code. Git stash -p, on the other hand, allows me to select what code should be left in the working directory for testing, with no need for a staging area.
black-tea 8y ago
It's interesting how people always talk about staging individual files. Did you know git supports staging individual lines? This is way more powerful and allows you to begin commiting sooner on any code base.

ufo 8y ago

It is possible to use git stash for that. In addition to being conceptually simpler it also allows you to run tests on the “partial commit” before commiting it.

GuiA 8y ago
git stash actually changes what's on the filesystem though (i.e. you cannot randomly open up something that is stashed in an arbitrary text editor).
- ufo 8y ago
  You could always just unstash things, I suppose. In the context I was talking about, the stash is only used to prepare a commit, and after that you can unstash everything. For longer term stashing I think named branches you easily checkout are a better alternative.
chrisweekly 8y ago
+1 for git stash -- but I don't like the idea of eliminating the staging area.

ori_b 8y ago

Do the same as vanilla git: git commit those three files That operation is still not implemented in git/fs, but it's planned.

war1025 8y ago

I wonder how much overlap there is between the "staging area is useless" and the "never rewrite history" crowds. Personally, I use staging area all the time to create a curated set of commits that make logical sense when putting them up for review. My workflow is generally to keep a very messy history of `XXX` commits until I am happy with what I've come up with. Then reset back to the branch point and using the staging area to build up logical changesets. I don't care about the history of my coming up with the solution, I care about presenting the solution in a way that makes sense to reviewers, including future me.

ori_b 8y ago
Interesting, so you commit things that are different from the code that is sitting in your working directory at the time of the commit?
- war1025 8y ago
  I use `git add -p` to selectively pick out chunks of code that fit together into commits. Later on, if I notice that I messed something up, I'll create a fixup commit and do an interactive rebase to squash it back into the correct commit.
  - e3b0c 8y ago
    In my opinion, `git add -p` should be the default, and a `-a` or alike to forcibly commit the entire working tree. I have developed a habit that I wouldn't feel comfortable if I haven't reviewed the chunks I am going to make into the commit.
    - erik_seaberg 8y ago
      Whereas I don't feel comfortable with untested work, so "git checkout -p" (undo a change) and "git stash -p" (postpone a change) are how I get the workspace clean enough to commit.
    - Rychard 8y ago

jcranmer 8y ago

Have a commit command line that lists only the three files in question. It's really not that hard. If you're going to suggest more complex scenarios, the answer usually boils down to in practice "you want an interactive commit anyways," with perhaps some form of (unpushed) history rewriting to move patch hunks around between different commits. The staging area is basically a half-baked, special commit that is easy to do manipulation on but hard to figure out what its actual state is (e.g., show me only the diffs that are in the staging area, or let me figure out what the hell is actually going on if I'm doing a complicated rebase). You know what would be better? Turn the staging area into a full, real commit and lower the friction of editing unpushed history to make it easy to move patch hunks in, out, and between these commits. It would help people who want commits to be atomic and therefore break WIP changes into multiple commits before publishing them for review.

war1025 8y ago
`git diff --cached` shows what is in the staging area
- slavik81 8y ago
  There's an alias, `git diff --staged`, that I find a little easier to remember.
deathanatos 8y ago
> Have a commit command line that lists only the three files in question. It's really not that hard. And how would you stage & commit only a portion of the changes made to a file? (Like the parents, I use the staging area daily, and I am quite thankful for its existence.)
- ori_b 8y ago
  > And how would you stage & commit only a portion of the changes made to a file? I wouldn't. That code is untested, and I have a thing against committing untested code. Git stash -p, on the other hand, allows me to select what code should be left in the working directory for testing, with no need for a staging area.

black-tea 8y ago

It's interesting how people always talk about staging individual files. Did you know git supports staging individual lines? This is way more powerful and allows you to begin commiting sooner on any code base.