[wyldfire]

> Git isn't that hard.

It's not, but if you don't use it mostly every day, or if you decide to "Delete repository and clone again" every time there's a problem, you won't ever get to learn how to fix it.

The staging area is totally unnecessary IMO. I think git would be easier if we didn't have it.

The term `checkout` is multiplexed to do more things than I would've guessed.

[ChrisSD]

I find the staging area useful. It especially helps when you only want to commit a change in part of a file or just generally reviewing a commit before it's a real commit. And also to double check I'm not going to be uploading any secret keys (which seems to happen to people more often than it should).

[jordigh]

The staging area is incidental. It's yet another place in which your code can be, and it confuses users. This is why Gitless has removed it.

https://gitless.com/#vs

You don't need the staging area to select hunks into a commit. The selected hunks could go straight into a commit. Selecting hunks is a different thing than putting the selection into an extra intermediate area between working directory and commit.

You don't need an extra intermediate area to review a commit. Commits are flexible and modifiable, so you can review the draft commit, modify it as necessary, and then publish it.

[tom_]

I always assumed it was there as an analogue of the state tracked by a UI such as TortoiseSVN's Commit dialog, or (though it's a lot longer since I lasted used it...) Perforce's changelists view. It's a list of files you've got checked out or modified: you tick the ones you want in the commit, right click to delete files or revert, double click to get a diff, that kind of thing. Between each deletion/reversion/diff/etc., the state of the tickboxes is retained, so you can sort of just fool about until you've got what you want.

But this sort of multi-step thing is often a pain to do from the command line, I find: unless you have some way of tracking the state between commands, it's no fun working through this list of items, building up a to do list that you then have to get done at the end with one uber command. And the staging area is this way of tracking the state when it comes to putting together your commit.

The gitless examples look to have many common possibilities licked, though, and perhaps that will suffice for most cases?

[cheerlessbog]

I didn't know about Gitless. The other interesting thing I see about it is that switching branches also switches out any uncommitted changes. On balance I think I find that less useful.

[derwiki]

Also helpful for committing changes in smaller atomic units

[CardenB]

I think the staging area should be a more intermediate usage pattern, at least.

[narnianal]

But you could also review the commit before pushing and then modify it instead.

[house9-2]

> The staging area is totally unnecessary IMO. I think git would be easier if we didn't have it.

Staging area / Index is one of the best features of Git for me.

If I end up having a bunch of semi related changes in-progress; being able to easily group those into individual commits is great.

> The term `checkout` is multiplexed to do more things than I would've guessed.

Agree

[pjc50]

You can do that in svn too with the "changelist".

[agapon]

svn cannot do partial file commits

[klyrs]

> The staging area is totally unnecessary IMO

Honestly, I think that 'stash' is the more problematic concept for me. Not that it's particularly bad, just that it's extra. Make a new branch for your awful code, check out your old head and keep going. I learned hg and then git, and IIRC stash was more comfortable for my team's established workflow.

And maybe I have good reason to hate it. One of the only times I've ever broken a repo is by attempting to stash partway through a messy merge. Never did figure out if that was pebcak or a bug, or if I could gracefully recover, because I was in the middle of something. I shed a tear, nuked the repo and found a better direction to merge.

Ever since that happened I've gotten much more comfortable making and deleting branches. Among other things, they're easier to clean up and have proper histories.

[OJFord]

> The staging area is totally unnecessary IMO. I think git would be easier if we didn't have it.

I can't even imagine not having it, I extremely rarely commit all changes, to the point where I really might as well alias add=add -p, and now I've thought of it I probably will.

> The term `checkout` is multiplexed to do more things than I would've guessed.

My rule is that if I think that, I've probably got the 'wrong' mental model.

Checkout gets the state of the worktree from somewhere else.

In its simplest usage, from another ref and changes to it.

With -b, as above, but with a new branch name.

With -- files, filter for only the given files, leaving HEAD where it is because moving it would be the opposite operation - taking the inverse list of files from current location to the specified one.

Etc.

[narnianal]

> The term `checkout` is multiplexed to do more things than I would've guessed.

Do you mean `pull`?

> The staging area is totally unnecessary IMO. I think git would be easier if we didn't have it.

It's an interesting POV. Especially since you can easily amend and rebase -i before pushing without any consequence. Thanks for the idea. I implement a git-like for a special use case at the moment and will certainly consider this.

[Seb-C]

I didn't use the staging area until I started to use git add -p. Now I use it very often to properly separate mixed changes into more logical commits.

It makes the staging very convenient to use. But without this command, I agree that it is a pain to use.