Disable git staging area

Question

I really don't like the git staging area, it just makes my life unnecessarily confusing.

Is it possible to disable it so that all edited and new files are in a single context? So that git diff shows the diff between the repository and my working directory (and I don't have to also type git diff --cached) and so that git ci checks in my whole working copy (not just the part that's staged).

If not, alternatives (like setting up cofigurations) so that it appears that I don't have a staging are would be great too.

I do not have the option of changing to a different DVCS and I don't want to learn to like the staging area. Please do not post to suggest these :(

Thanks, -Shawn

PS: I asked this on superuser.com, http://superuser.com/questions/192022/disable-git-staging-area, but that forum seems to have much less posted (only 118 tagged git compared to 4448 here)

Answer 1

You could just use git commit -a to commit all changed/deleted files. You would still have to add untracked files manually thought.

I came from Subversion and was confused by the staging area at first too. But you will find it to be very useful. If you stage changes you've tested but make more changes that break your build, you can reset back to your staged changes.

Answer 2

The staging area is (IMO) one of Git's greatest strengths and really shows how it's different from just about any other DVCS out there.

You can use

git commit -a

to automatically add changed files. For untracked files you are on your own though. Practice git add . && git commit.

If you don't like it use another VCS. Forced to use a git repository? See some of the available plugins that are compatible, such as hg-git.

---

Personally I would learn to play to git's strengths instead of fighting it. Imagine you are in the middle of a big messy branch, but you need to commit a few selective changes for production. Boom, git add [files] and then commit and push. Go back to work without messing anything else up. There are countless other examples, but that's perhaps the easiest to understand.

Answer 3

No. You learn to love it.

On a more serious note, git add -A; git commit is probably your friend. That way, you avoid most of the interactions with (and benefits of) the index.

git add -A is more powerful than the usual git commit -a. It will find new files as well as staging modified content and removing files that are no longer in the working tree.

Answer 4

Aliases are your friends.

For instance, you can create a diff command that does what you want with minimal typing: in your .gitconfig put

[alias]
        di = diff HEAD
        co = commit -a

You can then simply do git di and you get your own diff, or git co and get your own personal commit command.

Answer 5

and I don't want to learn to like the staging area. Please do not post to suggest these :(

Like all the others. I'm going to suggest you learn to like the staging area. It really is useful even though 90% of the time you'll be ignoring it.

If you currently don't find it useful then I think you're thinking about commits wrong. You're still thinking in terms of single files or everything at once. The correct way to think about commits is per feature/fix and features/fixes are often spread accross more than one file. You should group related changes into a single commit. And sometimes that group of changes does not encompass all the current changes. Which is when the staging becomes useful.

I know this is not what you want to hear but really, the moment you stop fighting the tool and learn to live with it is the moment it stops being "painful" to use the tool.