6 ms·

> the elimination of the staging area was enthusiastically received as a major reduction in complexity Well, that'd be a huge negative to me… it is much easier

> the elimination of the staging area was enthusiastically received as a major reduction in complexity Well, that'd be a huge negative to me… it is much easier to build up a commit piece by piece, verify that it's correct, and then commit it. The only two alternatives I can imagine are worse: disallowing partial commits (I use this feature all the time; I guess I could replace it by a temp commit on a branch and then so long as cherry-pick -p still exists, use that) or specifying it to git-commit (that would be one gnarly set of flags…) Sure, a git without a staging area is less complex. But it removes essential complexity, and would no longer solve my problems. (And in systems that lack it, like Perforce, I've sorely wanted it, and there was just not a good workaround. But yeah, that aspect of the VCS was simpler, I suppose…) I do agree teaching the staging area seems problematic. Newcomers struggle with it. I also agree with how the article mentions other commands sometimes effecting one or more of the staging area & working dir, and it being unclear when are where they effect what. `reset` is perhaps the most confusing command in that regard. Outside of "git reset", "git reset -p" and "git reset --hard", I'm looking at the manual while I run it. (Granted, those first 3 cover probably 99% of the use cases…)

jcranmer 6y ago
> The only two alternatives I can imagine are worse: disallowing partial commits (I use this feature all the time; I guess I could replace it by a temp commit on a branch and then so long as cherry-pick -p still exists, use that) or specifying it to git-commit (that would be one gnarly set of flags…) Are you aware that git commit --amend exists? That replaces anything I might ever be tempted to use the staging area for.
- Arelius 6y ago
  I'm not sure how you use --amend to do partial commits of a file.
  - jcranmer 6y ago
    Well, that would be solved with --interactive, would it not?
  - atombender 6y ago
    "git commit" takes the -p (or --patch) flag for partial commits of a file, just like "git add". (Some people prefer --interactive, but I think the patch mode is significantly superior.)
- deleted 6y ago
  [deleted]
- sagarm 6y ago
  There's a good chance the person you are replying uses git commit --amend all the time to modify commits in conjunction with git add -p. No, hg amend -i is much worse than git add -p. I do that when I have to use mercurial and there's significantly more mental overhead to make sure I'm not accidentally modifying a commit I did not intend to modify. Creating a "temporary" commit before I have a complete change is also annoying. And once you need to add a file, you're back to having a staging-like concept. IMO the staging area is fundamental complexity.
  - jcranmer 6y ago
    Perhaps it's a difference in workflow, but I really don't understand why managing a "temporary" commit is so mentally taxing. Especially because in my workflows, I'm often not managing a single commit but an entire stack of commits, for which the staging area adds no value. As I see it, the staging area is useless because it's basically a weird not-quite-commit-thing that you are more or less required to deal with (no way to opt out of it--several commands end up mucking about with the staging area even if you're not trying to use it). It feels like the better way to model it is to make it an actual commit, let it be manipulated as a regular commit, and then potentially improve the tooling around manipulating unpublished head commits as well.
    - feoren 6y ago
      Agreed. If you want to commit something that's not "reviewable" yet, just put it on another branch. Get used to committing things that aren't done yet! Hg does it right.
  - sushisource 6y ago
    OK, then rebase and squash after making a bunch of commits. I can see why someone might like staging, but clearly it can be built on top of other git functions. So, sorry, staging being "fundamental complexity" sounds petty BS to me. You like it, and that's fine, but it's in no way fundamental. I've used git for a long, long time, tried staging a few times and have never reached for it again.
- jayd16 6y ago
  So I'm working and committing as I go along instead of staging, I need to be super sure I only rebase and never pull or else I've made a huge mess? I think I'll stick with staging.
erik_seaberg 6y ago
I can’t build the staging area. I would much rather git stash -p the changes I don’t want to commit yet, and commit the workspace because that’s what I tested.
- magicalhippo 6y ago
  Yeah I want my actual files on disk to reflect what I'm about to commit. So ideally, IMHO, the staging area should work exactly in reverse of what it's currently doing.
  - anarazel 6y ago
    I regularly hack on a slightly larger feature, fix, whatever. Once it's working, I incrementally stage lines for the separate commits that'll make up something reviewable. Doing a line-by-line review of the change at the same time. Often I'll omit some too-verbose or too hacky debugging that I don't want to include. Once that's done I'll start a script that verifies that all the incremental commits individually pass tests (and maybe grab a coffee). While the tests run I'll do a separate pass over the commits. For me the staging is absolutely crucial, and I can't imagine wanting to go back.
    - magicalhippo 6y ago
      I'm not saying staging should go away. I'm saying it should work in reverse. Instead of having all the changes in your working directory and commit some temporary state not reflected in the working directory, I'd like to move my changes into a temporary area and then pick the lines into my working directory and commit that. That way I can compile and run tools etc on the code that will be committed before committing. If I'm not ready to commit everything, I could then stop the "commit mode" and my uncommitted changes would be brought back into the working directory. At least that's what I dream of.
      - stormbrew 6y ago
        Huh this is actually a kind of interesting idea. So basically if `git stash apply` had a --patch or --interactive mode? So the flow would be: <working on big change churn churn churn> > git stash > git stash apply -p <pick some things to have in working tree> > make test > git commit -a -m "First change!" > git stash apply -p <pick some more things> ...repeat... ? I could get behind that, and I personally like the index.
spaetzleesser 6y ago
For me the staging area is almost the most important feature of git. I often use it to stage new code that already and then step by step add more code that works. This only works if you use a GUI like Sourcetree . With the command like staging isn’t much fun.
- imron 6y ago
  I use the git command line almost exclusively and find it preferable to other tools for manipulating the staging area.
  - spaetzleesser 6y ago
    I have repeatedly tried to use it with the command line but I just can't get the hang of it.
    - imron 6y ago
      Which part gives you issues, adding things or removing things?
      - mtzet 6y ago
        Working at file granularity is fine, but I've never gotten a good workflow for using the CLI to stage individual hunks. Nothing beats selecting the lines I care about in magit (or any other GUI) and clicking to stage.
        etripe 6y ago
        git add --interactive <file>, then mark the file as staged and select the patch option if memory serves. It's not complex once you get the hang of it. The only problem I run into is not being able to split chunks further. I do agree a GUI lowers the barrier to entry.
        6y ago
jayd16 6y ago
If anything, I kind of wish git had as many named stages as you wanted. Its one of the nice features of Perforce but they screw it up by only allowing separation at the whole file level.
da39a3ee 6y ago
If you think the staging area is unintuitive you should see what emacs magit does( and I love emacs magit). You stage A, start typing a commit message, stage B, finish the commit message, commit, and lo and behold B isn’t in the commit. So in magit it feels like there’s a secret second staging area.
- marco_craveiro 6y ago
  Magit brings an immense clarity to git workflows; I suspect I would not rely on staging as heavily as I do, if it weren't for Magit.
remram 6y ago
I recently switched from gitk to qgit as my always-open repo status tool, and qgit doesn't show staged/unstaged changed separately like gitk. As a result, using the staging area suddenly has higher friction. What I found myself doing is using a plain old commit instead of a staging area. Where I would previously build a commit in the staging area before I finally create it, I now simply keep amending it until it suits my need. It oftens starts out with a message like "WIP". This also scales to building multiple commits (use --fixup instead of --amend, and checkout instead of stash). In practice the workflow is very similar and I was surprised by how little the removal of a core feature that I used all the time actually affects me.
Noumenon72 6y ago
I set PyCharm's Git client to auto-stage everything, and build up my commits using PyCharm's tools. You can go through your visual diff and hit checkboxes to say "put this chunk in the commit, exclude this chunk". Or you can get one piece of your commit ready, then create a new Changeset and have any new changes go into that changeset, able to be reviewed, committed, shelved, or rolled back separately. The problem with staging is I want every file I changed in one place so I can notice what changed and look through the diff together. Not to just show up at the bottom of the list .

jcranmer 6y ago

> The only two alternatives I can imagine are worse: disallowing partial commits (I use this feature all the time; I guess I could replace it by a temp commit on a branch and then so long as cherry-pick -p still exists, use that) or specifying it to git-commit (that would be one gnarly set of flags…) Are you aware that git commit --amend exists? That replaces anything I might ever be tempted to use the staging area for.

Arelius 6y ago
I'm not sure how you use --amend to do partial commits of a file.
- jcranmer 6y ago
  Well, that would be solved with --interactive, would it not?
- atombender 6y ago
  "git commit" takes the -p (or --patch) flag for partial commits of a file, just like "git add". (Some people prefer --interactive, but I think the patch mode is significantly superior.)
deleted 6y ago
[deleted]
sagarm 6y ago
There's a good chance the person you are replying uses git commit --amend all the time to modify commits in conjunction with git add -p. No, hg amend -i is much worse than git add -p. I do that when I have to use mercurial and there's significantly more mental overhead to make sure I'm not accidentally modifying a commit I did not intend to modify. Creating a "temporary" commit before I have a complete change is also annoying. And once you need to add a file, you're back to having a staging-like concept. IMO the staging area is fundamental complexity.
- jcranmer 6y ago
  Perhaps it's a difference in workflow, but I really don't understand why managing a "temporary" commit is so mentally taxing. Especially because in my workflows, I'm often not managing a single commit but an entire stack of commits, for which the staging area adds no value. As I see it, the staging area is useless because it's basically a weird not-quite-commit-thing that you are more or less required to deal with (no way to opt out of it--several commands end up mucking about with the staging area even if you're not trying to use it). It feels like the better way to model it is to make it an actual commit, let it be manipulated as a regular commit, and then potentially improve the tooling around manipulating unpublished head commits as well.
  - feoren 6y ago
    Agreed. If you want to commit something that's not "reviewable" yet, just put it on another branch. Get used to committing things that aren't done yet! Hg does it right.
- sushisource 6y ago
  OK, then rebase and squash after making a bunch of commits. I can see why someone might like staging, but clearly it can be built on top of other git functions. So, sorry, staging being "fundamental complexity" sounds petty BS to me. You like it, and that's fine, but it's in no way fundamental. I've used git for a long, long time, tried staging a few times and have never reached for it again.
jayd16 6y ago
So I'm working and committing as I go along instead of staging, I need to be super sure I only rebase and never pull or else I've made a huge mess? I think I'll stick with staging.

erik_seaberg 6y ago

I can’t build the staging area. I would much rather git stash -p the changes I don’t want to commit yet, and commit the workspace because that’s what I tested.

magicalhippo 6y ago
Yeah I want my actual files on disk to reflect what I'm about to commit. So ideally, IMHO, the staging area should work exactly in reverse of what it's currently doing.
- anarazel 6y ago
  I regularly hack on a slightly larger feature, fix, whatever. Once it's working, I incrementally stage lines for the separate commits that'll make up something reviewable. Doing a line-by-line review of the change at the same time. Often I'll omit some too-verbose or too hacky debugging that I don't want to include. Once that's done I'll start a script that verifies that all the incremental commits individually pass tests (and maybe grab a coffee). While the tests run I'll do a separate pass over the commits. For me the staging is absolutely crucial, and I can't imagine wanting to go back.
  - magicalhippo 6y ago
    I'm not saying staging should go away. I'm saying it should work in reverse. Instead of having all the changes in your working directory and commit some temporary state not reflected in the working directory, I'd like to move my changes into a temporary area and then pick the lines into my working directory and commit that. That way I can compile and run tools etc on the code that will be committed before committing. If I'm not ready to commit everything, I could then stop the "commit mode" and my uncommitted changes would be brought back into the working directory. At least that's what I dream of.
    - stormbrew 6y ago
      Huh this is actually a kind of interesting idea. So basically if `git stash apply` had a --patch or --interactive mode? So the flow would be: <working on big change churn churn churn> > git stash > git stash apply -p <pick some things to have in working tree> > make test > git commit -a -m "First change!" > git stash apply -p <pick some more things> ...repeat... ? I could get behind that, and I personally like the index.

spaetzleesser 6y ago

For me the staging area is almost the most important feature of git. I often use it to stage new code that already and then step by step add more code that works. This only works if you use a GUI like Sourcetree . With the command like staging isn’t much fun.

imron 6y ago
I use the git command line almost exclusively and find it preferable to other tools for manipulating the staging area.
- spaetzleesser 6y ago
  I have repeatedly tried to use it with the command line but I just can't get the hang of it.
  - imron 6y ago
    Which part gives you issues, adding things or removing things?
    - mtzet 6y ago
      Working at file granularity is fine, but I've never gotten a good workflow for using the CLI to stage individual hunks. Nothing beats selecting the lines I care about in magit (or any other GUI) and clicking to stage.
      - etripe 6y ago
        git add --interactive <file>, then mark the file as staged and select the patch option if memory serves. It's not complex once you get the hang of it. The only problem I run into is not being able to split chunks further. I do agree a GUI lowers the barrier to entry.
        6y ago

jayd16 6y ago

If anything, I kind of wish git had as many named stages as you wanted. Its one of the nice features of Perforce but they screw it up by only allowing separation at the whole file level.

da39a3ee 6y ago

If you think the staging area is unintuitive you should see what emacs magit does( and I love emacs magit). You stage A, start typing a commit message, stage B, finish the commit message, commit, and lo and behold B isn’t in the commit. So in magit it feels like there’s a secret second staging area.

marco_craveiro 6y ago
Magit brings an immense clarity to git workflows; I suspect I would not rely on staging as heavily as I do, if it weren't for Magit.

remram 6y ago

I recently switched from gitk to qgit as my always-open repo status tool, and qgit doesn't show staged/unstaged changed separately like gitk. As a result, using the staging area suddenly has higher friction. What I found myself doing is using a plain old commit instead of a staging area. Where I would previously build a commit in the staging area before I finally create it, I now simply keep amending it until it suits my need. It oftens starts out with a message like "WIP". This also scales to building multiple commits (use --fixup instead of --amend, and checkout instead of stash). In practice the workflow is very similar and I was surprised by how little the removal of a core feature that I used all the time actually affects me.

Noumenon72 6y ago

I set PyCharm's Git client to auto-stage everything, and build up my commits using PyCharm's tools. You can go through your visual diff and hit checkboxes to say "put this chunk in the commit, exclude this chunk". Or you can get one piece of your commit ready, then create a new Changeset and have any new changes go into that changeset, able to be reviewed, committed, shelved, or rolled back separately. The problem with staging is I want every file I changed in one place so I can notice what changed and look through the diff together. Not to just show up at the bottom of the list .