4 ms·

imo git is hard, because it is hard to think of history as a tree. also, problems we solve with git are harder than what we used to solve with subversion or cvs

by shepik 13y ago

imo git is hard, because it is hard to think of history as a tree. also, problems we solve with git are harder than what we used to solve with subversion or cvs. i mean, most of the git problems i or my colleagues ever encountered happened because of a rebase, or rebase + merge, or merge + rebase, or similar combinations, when we tried to rewrite history to make it clean and readable, and we never even think about "clean history" back then. You can grasp in about an hour concepts like "index", "staging area" and other that the article mentions.

Someone 13y ago
I don't think it is hard to think of history as a tree. SCM tools have been doing that for decades (with fewer branches) Also, git history is more like a DAG. Also, about that 'grasping in about an hour': way too often, reading some more confuses the hell out of you again. Witness: You can grasp in about an hour concepts like "index", "staging area" and other that the article mentions. So, is there a difference between index and staging area? Google "git index vs staging area" gives me top hit http://stackoverflow.com/questions/12138207/is-the-git-staging-area-just-an-index http://stackoverflow.com/questions/12138207/is-the-git-stagi..., which does not help me. Second hit is http://stackoverflow.com/questions/4084921/what-does-the-git-index-exactly-contain http://stackoverflow.com/questions/4084921/what-does-the-git.... Again, far from a clear answer. Further googling/clicking gets me to http://stackoverflow.com/questions/6716355/why-staging-directory-is-also-called-index-git-index http://stackoverflow.com/questions/6716355/why-staging-direc.... And no, the git-scm book at http://git-scm.com/documentation http://git-scm.com/documentation did not help _me_ either. It seems to have banned the use of 'index' as the (almost? More or less?) synonym for staging area. I think a large part of complaints about git are caused by its confusing user interface and confusing terminology. Yes, terminology may have been cleaned up officially, but 'the Internet' is littered with remnants of its history. Apart from that, one thing that I find confusing about the staging area is that it is invisible. Consequently, there doesn't seem to be a way to build what would get committed on as 'git commit' (do a 'git add X', then edit X. 'git commit' will commit the old content of X, but 'make' will use the edited content of X. Or am I confused again?)
- _ikke_ 13y ago
  index and staging area refer to the same thing. The staging area is a high-level concept, while index is more of an implementation detail (exists in .git/index).
Skinney 13y ago
The rule of thumb is to only use rebase for local commits (commits that haven't been pushed). This causes pain if people have commited, or will commit, work on a branch that has been rebased remotely. I've never really thought of Git history as a tree. I just think of it as a linked list of commits, and that I have more than one list available (branches).
- yxhuvud 13y ago
  What do you have if you have several lists with a common ancestor? You have a tree!
  - Skinney 13y ago
    I wasn't disagreeing, I simply said I never looked at git's history in that way. While I certainly do have a tree, I don't necessarily perceive it as such, especially when using "git log --graph --format=oneline --first-parent"

by shepik 13y ago

Someone 13y ago

I don't think it is hard to think of history as a tree. SCM tools have been doing that for decades (with fewer branches) Also, git history is more like a DAG. Also, about that 'grasping in about an hour': way too often, reading some more confuses the hell out of you again. Witness: You can grasp in about an hour concepts like "index", "staging area" and other that the article mentions. So, is there a difference between index and staging area? Google "git index vs staging area" gives me top hit http://stackoverflow.com/questions/12138207/is-the-git-staging-area-just-an-index http://stackoverflow.com/questions/12138207/is-the-git-stagi..., which does not help me. Second hit is http://stackoverflow.com/questions/4084921/what-does-the-git-index-exactly-contain http://stackoverflow.com/questions/4084921/what-does-the-git.... Again, far from a clear answer. Further googling/clicking gets me to http://stackoverflow.com/questions/6716355/why-staging-directory-is-also-called-index-git-index http://stackoverflow.com/questions/6716355/why-staging-direc.... And no, the git-scm book at http://git-scm.com/documentation http://git-scm.com/documentation did not help _me_ either. It seems to have banned the use of 'index' as the (almost? More or less?) synonym for staging area. I think a large part of complaints about git are caused by its confusing user interface and confusing terminology. Yes, terminology may have been cleaned up officially, but 'the Internet' is littered with remnants of its history. Apart from that, one thing that I find confusing about the staging area is that it is invisible. Consequently, there doesn't seem to be a way to build what would get committed on as 'git commit' (do a 'git add X', then edit X. 'git commit' will commit the old content of X, but 'make' will use the edited content of X. Or am I confused again?)

_ikke_ 13y ago
index and staging area refer to the same thing. The staging area is a high-level concept, while index is more of an implementation detail (exists in .git/index).

Skinney 13y ago

The rule of thumb is to only use rebase for local commits (commits that haven't been pushed). This causes pain if people have commited, or will commit, work on a branch that has been rebased remotely. I've never really thought of Git history as a tree. I just think of it as a linked list of commits, and that I have more than one list available (branches).

yxhuvud 13y ago
What do you have if you have several lists with a common ancestor? You have a tree!
- Skinney 13y ago
  I wasn't disagreeing, I simply said I never looked at git's history in that way. While I certainly do have a tree, I don't necessarily perceive it as such, especially when using "git log --graph --format=oneline --first-parent"