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, https://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)

Glossotomy

I'd never remove staging even if possible, but I voted you up just to see if it's possible. – Blackberry

Being a developer is all about learning. I can't even imagine why you'd want to ignore your tools and not learn how to use their biggest strengths. Do you also object to learning new APIs or new design patterns? :/ – Bengt

@Daenyth: I have no problem with learning new tools. I understand how this could be a useful option for some people at some times. I am pretty sure that in my situation it is not useful. I think it is silly that git forces you to use certain technologies (like the staging area) rather than simply allowing you to use them. Sometimes you need a screwdriver and sometimes a hammer, but I would be pissed off if my screwdriver had a built in hammer that I had to navigate around just so that I could unscrew my doorknob. – Glossotomy

+1 ... and I too would rather avoid the staging area cause I'm used mercurial. Think of all the steps now to push code into a repo compared to crappy old SVN (Commit). For Git and HG (minus the add): Add -> Commit -> Push -> Nope -> Pull -> Update -> Merge -> Commit -> Push. One could argue aww its just one more step and you can use aliases but some times a little more simplicity is nice. – Lapidary

Answer 1

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

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.

Blair

Why should we learn to love it if it is possible to automate all those manual staging procedures? – Spermato

Purely a matter of opinion that you "learn to love it". The staging area simply gets in the way of my normal use-cases. – Alexi

When I read "No. You learn to love it", I immediately thought "oh cool. he's going to say never do git add -A. But then he goes on to say exactly that. I don't get it. If you love the staging area, then the last thing you want to do is always bypass it by doing git add -A; git commit Isn't the whole point of the staging area is that you want a different set of files in the working and staging areas, which means you manually and explicitly control what gets in there, without a git add -A wildcard. – Exedra

Answer 2

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.

Cox

but then git di will not show me what is in my working dir, I want git diff to show me the change that will be committed when I do commit -a. – Glossotomy

Also, I cannot set co = commit -a in my rc because then I couldn't commit only one file (via git ci foo) because it complains about clash between -a and explicit file list. – Glossotomy

@sligocki: I changed the alias so that git di gives you what you indicated in your first comment. As for your 2nd comment: you can commit a single file with the usual git commit foo. – Cox

Ah, great, thanks for the diff HEAD suggestion, that looks helpful. As for the second comment, I would rather have one command for both. If not, I will probably continue to type git commit -a (it's become second-nature at this point anyway). – Glossotomy

Answer 3

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.

Blackberry

Yep, I always use git ci -a these days, but (unfortunately) I cannot set ci = commit -a in my rc because then I couldnt' commit only one file (via git ci foo) because it complains about clash between -a and explicit file list. – Glossotomy

Answer 4

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.

Epithelioma

Not an option to use another. I'm stuck with this tool. – Glossotomy

@sligocki: You can use several options instead of git to emulate a git repository. See hg-git. – Epithelioma

no, I can't. I'm really tired of people saying this! I am using tools that are built on top of git, I do not have an option to use another DVCS or these tools will not work and the entire advantage of using a DVCS in the first place would be gone. – Glossotomy

@sligocki: Don't use tools, use the CLI. Really it isn't that complicated. – Epithelioma

@Josh K: How hard is this to understand! I work in a company that has a central perforce repository. Most people here use p4, but I think that p4 is antiquated and disasterous, we have a tool built on top of git as an alternative that allows all the beauty and wonder of DVCS. My choice is to: A) use p4, B) use the tool built on git and thus us git or C) roll my own. I do not want to use p4 or roll my own. So yes, it is rather complicated even though you think it couldn't possibly be! – Glossotomy

@sligocki: Considering you don't mention any of that in your initial question I would say pretty darn hard. – Epithelioma

@Josh K: Right, I didn't mention any of this because it isn't relevant. I just want to know how to disable the staging area. This question does not require you to know all the details of why. But you make it seem like I'm an idiot and should just use X and Y. You are not answering my question and not helping me because you think you know better than me. – Glossotomy

@sligocki: Those details are relevant to the question. – Epithelioma

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.

Magdeburg

Thanks slebetman, I do see why the staging area could be useful. It is not actually painful for me right now, just makes things more complicated, every once and a while I'll run git diff and be confused why some of the files aren't there. In my situation, I'm actually pushing from git into a perforce repo, so the git revisions are only for me and so can be much more crude. So I do not find myself wanting to craft the revision history, just use it to revert to a previously working state or try new development paths. – Glossotomy

Rather than doing that, try instead making your changes, and then use git diff only to see "Ok, what have I yet to add to the current commit". If you see that the difference is what you want to add, then add it. If not, then delete or ignore it. Keep working until git diff shows no changes, then you will be ready to commit your changes. – Hepato