Hacker News Reader

Comment by ori_b | Hacker News Reader

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://gitless.com/

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.

Could you elaborate on this workflow? I'm trying hard to think of one and not coming up with anything.

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.

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...

Doesn't git reset do what you want? For example git reset <remote>/<branchname> would usually do it for me, but you could just as easily do it to any other commit.

> 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.

Mercurial patch queue is pretty much that. You can also use temporary commit and phases to ensure they are not visible from outside your local repository.

I have never really understood why git introduces all this weird concepts (staging, stash) for what are just temporary commits in the end.

I use branches for this, and private remote repos. I thought that stash was magical and cool until that time I stashed in the middle of a merge and dug into the details of stash...

If I hate the state of my experimental branch, I kill it. If I want to keep parts, I cherry-pick them over to another experimental branch. When I want to keep fractions of patches, I manually copy deltas across with git-difftool (which was the only real reason I was stashing anyway). And when I finally have a branch that I'm happy with keeping, then I use "git merge -i" to collect the mini-commits into a sensible history

If you are committing subsets of your work, how can you guarantee than each commit is a working version of the code? Some committed code being dependent on uncommitted code. Or am I missing something?

I don't know... I just know. Is it that hard? I'm always pushing to remote and triggering CI and I rarely break the build.

I use it a lot.

Sometimes, you want to have a temporary snapshot, but not a commit.

So I write some code, it works, but I'm thinking of trying some things out. I stage the working code and make more diffs. Now I can have my editor show the diffs between my stage and my new changes. And I can easily rollback individual files or re-stage some more files.

Until I am satisfied. And now decide to make a commit.

I could just make them all commits, and then do a interactive rebase as well. And I do that too. But sometimes the staging area is just simpler and quicker. With git status I can see it at a glance. Etc.

My main use is keeping debug statements (print, pdb) separate from things I want to commit. Like the others, this is daily use for me.

This shows what's wrong with neo-hacker news. Actual scientific studies are downvoted and guessworks and 'anecdata' are upvoted.

Truly jumped the shark.

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.)

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.

Reply on news.ycombinator.com