6 ms·

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.

by 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...
      - black-tea 8y ago

by ori_b 8y ago

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...
    - black-tea 8y ago