[kazinator]

The concept of the git staging area is utterly superfluous. All local changes that are propagated to the version control system should go directly into a durable commit object, and not to a pseudo-commit object that isn't a commit, and that can be casually trashed.

That commit object could be pointed at by a separate COMMIT_HEAD pointer. If you have a COMMIT_HEAD different from HEAD, then you have a commit brewing. Finalizing the commit means moving HEAD to be the same as COMMIT_HEAD. (At that time, there is a prompt for the log message, if one hasn't been already prepared.)

Your "staged" changes are then "git diff HEAD..COMMIT_HEAD", and not "git diff --cached".

Speaking of which, why the hell is "cached" a synonym for "in the index"? Oh, because the index holds a full snapshot of everything. But that proliferation of terminology just adds to the confusion.

I can't think of any other area of computing in which "cache" and "index" are mixed up.

[saagarjha]

I like the staging area, though–at any given time I always have code that I do not want to put in a commit object (perhaps I changed some build flags, or my IDE touched some files I don't care for, or…) However, I do agree 100% that all the terminology is pretty bad.

[cxr]

The sin of Git's staging area is that Git forces it into the default interaction path—requiring you to take it into consideration whether or not you're interested in only committing some of the changes. Git should default to including all changes, and iff you direct it to (i.e. by explicitly specifying `git add`) should you have to take into consideration the notion that some changes are staged and others aren't.

[phorkyas82]

I'm generally also one of the git sceptics - Though I loved staging for a while as for the fine grained control. `git add --all` just might not do the right thing - for paranoids like me. Just recently got to know you can skip the staging by appending the paths of the changed files you want to commit after `git commit -m "awesome commit"` - neat.

[kazinator]

You can skip the explicit staging using

  git commit --patch

then interactively select the specific changes by diff hunk.

It combines with --amend.

[kazinator]

Would you like the staging area less if it was an object of exactly the same type as a commit, referenced by CHEAD (commit head) instead of HEAD?

[erik_seaberg]

Only the workspace can be built and tested, so the workspace is what should be committed. We should be stashing anything we don't want to test and commit yet.

[kjeetgill]

I'm trying to keep out of this fight, but how are you planning on just stashing one hunk without staging?

[kazinator]

The stash is another feature that should use the regular commit representation. Well, somehow. Yes, the stash is different in that it preserves (or can preserve) uncommitted changes, as well as staged changes, and it can tell these apart.

However, if the staging area is relaced by a CHEAD commit ("commit head") whose parent is HEAD, then the problem of "stashing the index" completely goes away. You don't stash staged changes because they are already committed into the staging commit CHEAD.

That said, the stash feature could work with this CHEAD. Stashing the staged changes sitting in CHEAD could propagate them into the stash somehow (such as by a reference to that commmit). Then CHEAD is reset to point to HEAD, and the changes are gone. A single stash item consisting of work tree changes and staged changes could simply be an object that references two commits: a commit of working changes committed just for the stash, and a reference to the CHEAD which existed at that time. It could be that one is the parent of the other. So that is to say, a commit is made of the working copy changes, parented at the CHEAD. The stash then points to the SHA of that commit.

Intuitively, I know this would work, because in the existing Git, I could easily implement this workflow instead of using the stash. Given a tree of local changes, I could "stage" some of them by creating a commit with "git commit --patch". Then "stash" rest of them into another commit "git commit -a". Then, create a branch or tag for that two-commit combo, and finally get rid of it with "git reset --hard HEAD^^". Later, I could easily recover the changes from that branch, either by cherry picking, or doing a hard reset to them or whatever.

Speaking of which, an example of how stashes are limiting because they aren't commits, think of how you can't do:

   git reset --hard stash@{0}  # wipe it all away and make it like this stash

You can't do that because a "reset --hard anything" cannot reproduce a state where you have outstanding working copy changes and/or an uncommitted index, but "stash apply" or "stash pop" are saddled with that requirement.

The requirement of reproducing working changes and staged ones from a stash represented as a two-commit combo is very simple. You cherry pick one normally and make it the CHEAD (the aforementioned special head for pointing to a commit being staged). Then the other one is cherry-picked with -n, so it is applied as local changes.

[erik_seaberg]

“git stash push --patch” lets you choose hunks to copy into the new stash and clean out of the workspace. It’s pretty similar to “git add --patch” for choosing hunks to stage.

[GeorgeTirebiter]

Check out: https://gitless.com/

[icedchai]

Git has weird terminology. Though a lot of commercial SCMs are also a bit strange. Example: Perforce which has depots and shelves. At least with git, I can create a branch without waiting 2 weeks for the IT department.

[FartyMcFarter]

Perforce shelves make total sense. "Shelving" something means literally what the command does - setting them aside and saving them.

[icedchai]

It “sort of” makes sense. When a company shelves a movie, they’re probably never finishing it. When I shelve my code, I’m probably coming back to it at some point soon. For example, I worked at a place that would have everyone “shelve” all their code before code review. In that context it didn’t make sense to me.