6 ms·

Opinions obviously vary. The staging area is one of the most useful things about Git for me, and I use it just about every day.

ori_b 8y ago
But I've got some usability studies to back the anti-staging stance up. Take a look at the research by the gitless folks: https://spderosso.github.io/oopsla16.pdf https://spderosso.github.io/oopsla16.pdf, https://gitless.com/ https://gitless.com/
- fxfan 8y ago
  This shows what's wrong with neo-hacker news. Actual scientific studies are downvoted and guessworks and 'anecdata' are upvoted. Truly jumped the shark.
  - theamk 8y ago
    Have you read the paper, especially their study design?(p11/302 is a good summary, also last 5 pages for actual instructions). They have sample size of 10 people, and they specifically choose a very basic workflow. This study design is a real problem -- even after I have read the paper, I am not convinced that I should be using gitless. Their graph looks science-y, but the small sample size and non-representative experiment design means the conclusion do not apply to my work. Reading this paper is reading a DB benchmark which only used rows with two integer fields in all their tests. Sure, it is interesting reading, but unless your workflow is exactly that, it is useless in real life. (Disclaimer: it is entirely possible that gitless is better than git in all workflows, not just the one described in the paper. But even if it is the case, I would not know about it, at least not from the gitless site.)
  - jpitz 8y ago
    I'm not sure I put a lot of faith in that study to measure anything other than that new users of a VCS are confused by the existence of a staging area.
- phs2501 8y ago
  I don't doubt that not having the staging area would make it better for new users, as it is certainly conceptually simpler to just commit everything. And for those who's revision control model is always linear commits of what's in the working copy, it really is just added work and complexity. But it enables other workflows (that I personally happen to use a lot) that are easy with staging and /very/ inconvenient without. So yeah, feel free to leave it out of your implementation; it doesn't seem like something that'd fit into the plan9 mindset anyway. But it is removing a very useful tool to some people.
  - jdsully 8y ago
    Could you elaborate on this workflow? I'm trying hard to think of one and not coming up with anything.
    - black-tea 8y ago
      I often make many changes at once and then begin to commit pieces of it incrementally as I go. Each commit should represent a perfectly valid version of the code base, but your working directory rarely represents a valid version during development. Without the staging area I wouldn't be able to begin commiting, and therefore using git, until much later, maybe days later.
      - kstenerud 8y ago
        I follow a similar workflow: 1. Make exploratory modifications 2. "git add" pieces that I think are "commit worthy", even if I'm not sure I want to actually commit it yet (still exploratory work). 3. If I decide I don't like the latest set of modifications, I clear them all, going back to what's in my pseudo-commit. 4. Once I'm happy with it as a whole, I turn it into a real commit, complete with message. What would be really nice is some sort of "pseudo-commit stack" whereby you can do this workflow, but every mini-commit goes into a stack that you can unwind to whatever point you want if it turns out that you've been going down a blind alley. If pseudo-commit stacks had first class treatment, you could even stash them, which would be great if some other emergency came along that you had to deal with now. Internally, you could create some kind of HEAD-like pointer for this, store commits that go from HEAD to PSEUDOHEAD, and then when you're finally ready to commit, squashes everything from HEAD to PSUEDOHEAD and follows standard commit procedure from there. Or maybe you could implement it as a "reset HEAD" kind of thing to collapse the pseudo-commits, which then allows you to use standard partial commit semantics if needed. Actually, now that I think of it, I could do a poor man's version by tagging REALHEAD before I start, making actual, real commits as I go, and then "git reset REALHEAD" to start building the actual commit I want...
pytyper2 8y ago
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

But I've got some usability studies to back the anti-staging stance up. Take a look at the research by the gitless folks: https://spderosso.github.io/oopsla16.pdf https://spderosso.github.io/oopsla16.pdf, https://gitless.com/ https://gitless.com/

fxfan 8y ago
This shows what's wrong with neo-hacker news. Actual scientific studies are downvoted and guessworks and 'anecdata' are upvoted. Truly jumped the shark.
- theamk 8y ago
  Have you read the paper, especially their study design?(p11/302 is a good summary, also last 5 pages for actual instructions). They have sample size of 10 people, and they specifically choose a very basic workflow. This study design is a real problem -- even after I have read the paper, I am not convinced that I should be using gitless. Their graph looks science-y, but the small sample size and non-representative experiment design means the conclusion do not apply to my work. Reading this paper is reading a DB benchmark which only used rows with two integer fields in all their tests. Sure, it is interesting reading, but unless your workflow is exactly that, it is useless in real life. (Disclaimer: it is entirely possible that gitless is better than git in all workflows, not just the one described in the paper. But even if it is the case, I would not know about it, at least not from the gitless site.)
- jpitz 8y ago
  I'm not sure I put a lot of faith in that study to measure anything other than that new users of a VCS are confused by the existence of a staging area.
phs2501 8y ago
I don't doubt that not having the staging area would make it better for new users, as it is certainly conceptually simpler to just commit everything. And for those who's revision control model is always linear commits of what's in the working copy, it really is just added work and complexity. But it enables other workflows (that I personally happen to use a lot) that are easy with staging and /very/ inconvenient without. So yeah, feel free to leave it out of your implementation; it doesn't seem like something that'd fit into the plan9 mindset anyway. But it is removing a very useful tool to some people.
- jdsully 8y ago
  Could you elaborate on this workflow? I'm trying hard to think of one and not coming up with anything.
  - black-tea 8y ago
    I often make many changes at once and then begin to commit pieces of it incrementally as I go. Each commit should represent a perfectly valid version of the code base, but your working directory rarely represents a valid version during development. Without the staging area I wouldn't be able to begin commiting, and therefore using git, until much later, maybe days later.
    - kstenerud 8y ago
      I follow a similar workflow: 1. Make exploratory modifications 2. "git add" pieces that I think are "commit worthy", even if I'm not sure I want to actually commit it yet (still exploratory work). 3. If I decide I don't like the latest set of modifications, I clear them all, going back to what's in my pseudo-commit. 4. Once I'm happy with it as a whole, I turn it into a real commit, complete with message. What would be really nice is some sort of "pseudo-commit stack" whereby you can do this workflow, but every mini-commit goes into a stack that you can unwind to whatever point you want if it turns out that you've been going down a blind alley. If pseudo-commit stacks had first class treatment, you could even stash them, which would be great if some other emergency came along that you had to deal with now. Internally, you could create some kind of HEAD-like pointer for this, store commits that go from HEAD to PSEUDOHEAD, and then when you're finally ready to commit, squashes everything from HEAD to PSUEDOHEAD and follows standard commit procedure from there. Or maybe you could implement it as a "reset HEAD" kind of thing to collapse the pseudo-commits, which then allows you to use standard partial commit semantics if needed. Actually, now that I think of it, I could do a poor man's version by tagging REALHEAD before I start, making actual, real commits as I go, and then "git reset REALHEAD" to start building the actual commit I want...

pytyper2 8y ago

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.