4 ms·

Ugh, this is terrible, the index is git's best feature. I kind of see where you're coming from with the idea of squashing together commits before pushing but it

Ugh, this is terrible, the index is git's best feature. I kind of see where you're coming from with the idea of squashing together commits before pushing but it seems like a lot of awkwardness and overhead for the really basic use case of committing a bunch of files without doing it all in one command. Maybe it's just my OCD tendencies but I actually do spend time crafting the perfect commit, picking only the hunks/lines that matter and all that. I think if people are taught git focusing on the index/staging area, it makes a lot more sense and you have much fewer problems.

kazinator 12y ago
You can pick out the hunks and lines that matter using "git commit --patch". This does the "git add --patch" and "git commit" in one step, so you never see any index. Face it, the git index is an exaust manifold bolted on to a bicycle. This can be proven. Any argument you make for how the git index is useful is easily knocked down with a counterargument which shows how it it is redundant, because existing mechanisms uniformly handle that case. Moreover, the index can be shown to complicate git. For instance when viewing differences with "git diff" you have: index to working ("git diff"), HEAD to index ("git diff --cached") or HEAD to working ("git diff HEAD"). This cruft all goes away if there is no index: you can just have "git diff" for the usual case of "show me what's different between the branch and working copy", like in virtually every other revision control system on the planet. > I think if people are taught git focusing on the index/staging area, it makes a lot more sense and you have much fewer problems. Absolutely no disagreement there. The index is there (complaining won't make it go away), and you have to know about it, otherwise you will not understand what is going on in some situations. People learning git must learn about the index upfront and know things such as "git diff" diffing against the index, or that the successful parts of a merge are in the index whereas the conflicts are unstaged and things of that sort.

kazinator 12y ago

You can pick out the hunks and lines that matter using "git commit --patch". This does the "git add --patch" and "git commit" in one step, so you never see any index. Face it, the git index is an exaust manifold bolted on to a bicycle. This can be proven. Any argument you make for how the git index is useful is easily knocked down with a counterargument which shows how it it is redundant, because existing mechanisms uniformly handle that case. Moreover, the index can be shown to complicate git. For instance when viewing differences with "git diff" you have: index to working ("git diff"), HEAD to index ("git diff --cached") or HEAD to working ("git diff HEAD"). This cruft all goes away if there is no index: you can just have "git diff" for the usual case of "show me what's different between the branch and working copy", like in virtually every other revision control system on the planet. > I think if people are taught git focusing on the index/staging area, it makes a lot more sense and you have much fewer problems. Absolutely no disagreement there. The index is there (complaining won't make it go away), and you have to know about it, otherwise you will not understand what is going on in some situations. People learning git must learn about the index upfront and know things such as "git diff" diffing against the index, or that the successful parts of a merge are in the index whereas the conflicts are unstaged and things of that sort.