4 ms·

Not quite. The git index (also called staging area) is basically the schedule of changes that are to make up the next changeset once you hit "git commit". This

Not quite. The git index (also called staging area) is basically the schedule of changes that are to make up the next changeset once you hit "git commit". This is actually why I consider the index an anti-feature. It not only allows you to do partial commits (practically every VCS does), but encourages it and there's a good chance that you may do it wrong by accident. This can result in broken revisions (because you're committing a state that may have never actually existed on your disk, let alone did compile or passed tests) and create problems for anything from "git bisect" to nightly builds. The proper way, as far as I'm concerned, is to do the inverse: use "git stash" instead to remove all changes that you do not need, then compile and test what is in your working tree and only then commit the tested version. Afterwards, apply the stashed changes to get the working tree back to its original state. This way you can minimize the risk of broken commits.

obsurveyor 12y ago
So much of this comes down to how a particular team uses git and the handling and organization of commits. The only thing you can really "do wrong" with git is push prematurely. Before that, you always have a chance to fix things or tidy things up. git allows you to package commits up with the interactive rebase before you push them upward to the source. What you commit now isn't necessarily what gets pushed upward. It doesn't matter if you broke the compile with the commit, you still have a chance to fix it before a push. If it hasn't been pushed, no one will necessarily ever know or see it. The whole point of git is that you can break the crap out of your local repo/branch and still have a chance to fix it before the changes ripple outward and become permanent. It also sounds like you're describing a workflow that entails working off master instead of using feature branches, which is going to create a lot more pain than there needs to be.
Shorel 12y ago
As a developer that's actually something I love git for. In a big company with several tickets describing errors in the system, I can work on several issues at the same time. Or explore different ideas and implementations. Now, the issue with the compile and testing can be real, but I have an easy workaround. I have another working copy/checkout of the repository, called <repository>-ro. I never edit files in the read only copy, unless it's to fix a merge conflict. All tests and merges are done in this other copy. Any revision does eventually exists on disk, in this copy.
- rbehrends 12y ago
  You don't need a staging area if you want to just commit selectively. No VCS that I know of will stop you from doing just that if you really want to. bzr/fossil/git/hg/mtn/svn commit path1 ... pathn will selectively commit only the listed files/directories (some of them will even allow you to commit individual hunks, as in "git add -p", if you like to live dangerously). The biggest problem with the staging area is that (1) it can happen accidentally that you forgot to "git add" a file or (2) it really only gives you any advantage over selective commits when you stage a non-trivial selection of files, which is exactly where things have a chance of going wrong.
  - obsurveyor 12y ago
    What am I missing, just --amend the commit with the stuff you forgot? Also, with 'git add -i' you can stage individual hunks of a change instead of the whole change. This can be useful when you need to break up changes into multiple commits. I don't think you can 'git stash' your way out of that situation.
david-given 12y ago
You mean that when you add a file to the index it copies it? So I can then change the file and the changes won't get committed? That seems... very wrong?
acjohnson55 12y ago
I agree! My success rate at trying to split changes into two compilable commits is probably like 50%. Unfortunately, I don't think stashing helps much either. It's still too cumbersome to stash only some changes. If you're successful on the first shot, awesome. But much like the partial commit case, if the changes you left unstashed don't actually compile or pass tests, adjusting the partition between the changes to commit and not to commit is still a huge pain.

obsurveyor 12y ago

So much of this comes down to how a particular team uses git and the handling and organization of commits. The only thing you can really "do wrong" with git is push prematurely. Before that, you always have a chance to fix things or tidy things up. git allows you to package commits up with the interactive rebase before you push them upward to the source. What you commit now isn't necessarily what gets pushed upward. It doesn't matter if you broke the compile with the commit, you still have a chance to fix it before a push. If it hasn't been pushed, no one will necessarily ever know or see it. The whole point of git is that you can break the crap out of your local repo/branch and still have a chance to fix it before the changes ripple outward and become permanent. It also sounds like you're describing a workflow that entails working off master instead of using feature branches, which is going to create a lot more pain than there needs to be.

Shorel 12y ago

As a developer that's actually something I love git for. In a big company with several tickets describing errors in the system, I can work on several issues at the same time. Or explore different ideas and implementations. Now, the issue with the compile and testing can be real, but I have an easy workaround. I have another working copy/checkout of the repository, called <repository>-ro. I never edit files in the read only copy, unless it's to fix a merge conflict. All tests and merges are done in this other copy. Any revision does eventually exists on disk, in this copy.

rbehrends 12y ago
You don't need a staging area if you want to just commit selectively. No VCS that I know of will stop you from doing just that if you really want to. bzr/fossil/git/hg/mtn/svn commit path1 ... pathn will selectively commit only the listed files/directories (some of them will even allow you to commit individual hunks, as in "git add -p", if you like to live dangerously). The biggest problem with the staging area is that (1) it can happen accidentally that you forgot to "git add" a file or (2) it really only gives you any advantage over selective commits when you stage a non-trivial selection of files, which is exactly where things have a chance of going wrong.
- obsurveyor 12y ago
  What am I missing, just --amend the commit with the stuff you forgot? Also, with 'git add -i' you can stage individual hunks of a change instead of the whole change. This can be useful when you need to break up changes into multiple commits. I don't think you can 'git stash' your way out of that situation.

david-given 12y ago

You mean that when you add a file to the index it copies it? So I can then change the file and the changes won't get committed? That seems... very wrong?

acjohnson55 12y ago

I agree! My success rate at trying to split changes into two compilable commits is probably like 50%. Unfortunately, I don't think stashing helps much either. It's still too cumbersome to stash only some changes. If you're successful on the first shot, awesome. But much like the partial commit case, if the changes you left unstashed don't actually compile or pass tests, adjusting the partition between the changes to commit and not to commit is still a huge pain.