Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

Thanks, -Shawn

share|improve this question
Since seems to have way more posts about git (4448 vs. 118), I asked the same question over there: – sligocki Sep 30 '10 at 20:36

The staging area is a core concept of Git. I also thought it unnecessary at first, but it can be really useful when you must commit only some changes.

So my suggestion is either to

  • get used to it,
  • or switch to another SCM that doesn't use a staging area.

git config "commit -a"
share|improve this answer
It is not an option for me to switch to another SCM, I am working with a git repo. I am simply trying to customize one of the design choices I don't like. – sligocki Sep 23 '10 at 18:45
BTW, you don't need to use the staging area to selectively commit only some changes. You can do 'git ci file1 file3' to only commit a few files straight from working copy. The staging area is only another level of indirection that some people might find useful. I don't. – sligocki Sep 23 '10 at 18:47
Hm, thanks for the git config suggestion, that seems like a partial solution. – sligocki Sep 23 '10 at 18:52
@sligocki: 1) Yes, it is an option. 2) I was talking about changes in the same file. git add -p is much more convenient than diff/un-edit/commit/patch. – grawity Sep 23 '10 at 19:20
1) No, HgGit really isn't an option for me. Not only is the repo git, but several tools (to do code reviews, syncing, etc.) are built on top of git. I would have to write completely new tools to use hg and I have no intention of that :/ 2) Thanks for the hint on git add -p, never tried it, but I don't generally find a need to break up commits with such granularity. I can imagine how the staging area could be useful, but for me, right now, it isn't, so I'd like to disable it. It appears the answer is that I cannot :( – sligocki Sep 29 '10 at 21:26

You can (almost) forget about it if you always do "git commit -a ..." (i.e., commit all changes to files git has under version control). But now and then you'll need the staging area: Say you have changes to a bunch of files, and only want to checkin some of them. It is handy to be able to go "hack, hack, hack, git add file1, hack hack hack, git add file2, hack hack, git commit -m change1, hack more, git add file1 file2 file3, git commit -m change2"

share|improve this answer
I do not like this style of committing because it could mean that an intermediate commit is totally non-functional because it depended on changes not in the work space. I prefer to be able to build and run tests and then commit everything, assuring that each commit builds and runs tests on it's own. – sligocki Feb 4 '13 at 21:26
@sligocki, I heartily agree with you. But that is an issue of develper discipline, not something a tool could hope to enforce. – vonbrand Feb 4 '13 at 22:44
@vonbrand: A commit can function as a staging area, so I don't think your argument explains why there is a need for the extra concept (staging area) as you claim. For example, there could instead have been a flag to git commit that squashes the previous commit together with the local changes. – Croad Langshan May 22 '15 at 20:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .