3 ms·

I used to be right there with you. I knew svn and I just wanted to port that knowledge over to git and start working. The problem was that the git interface is

by sofal 15y ago

I used to be right there with you. I knew svn and I just wanted to port that knowledge over to git and start working. The problem was that the git interface is similar enough to svn that it lets you use it almost like svn (add, commit, status, checkout, etc) and leads you to believe that it is fundamentally like svn. So whenever the first non-svn thing comes along it suddenly seems way too complicated. It seems like it's svn except with a whole lot of extra complicated crap added on. I told myself I'd eventually climb this gigantic-seeming learning curve, but I kept putting it off because it looked like such a huge obstacle. One day I finally sat down and starting going through the Pro Git book. After reading about the fundamentals of git I finally realized that this is ultimately no more complicated than a first year data structures class. It's just a stupid directed graph. All this wasted time scratching my head, only to find out that it's just a directed graph with labels attached to the nodes called 'branches'. All the crazy git commands with all the crazy options are just hacks that let you look at and fiddle with this stupid graph. Ultimately when you want your repository to be in a certain state, you first figure out what you want the graph to look like and then you use whatever git commands you want to make it so. It's hard to explain how fundamentally simple it is. The actual interface doesn't make it seem like it's simple, and all the terms that everything has doesn't make it seem simple, but it is all a bunch of tools and terminology built on top of a simple data structure. Unlike many tools, it is easier to understand the internals of git than the externals. But once you understand the internals, then you can practically speed read an article like this in the same way you could speed read an article explaining for/while loop syntax.

cpeterso 15y ago
> Unlike many tools, it is easier to understand the internals of git than the externals. But why should that be? For example, the git docs use different terms for the same thing (e.g. cache, index, stage). Also, the git tools overload the same command for different purposes (e.g. git add tracks new files or stages pending changes from existing files; git reset can unstage pending changes or revert committed changes). These are different functional procedures that happen to share implementation details.
- Xurinos 15y ago
  Don't use "git reset" to revert committed changes. Well... do, but be careful... The word "revert" is problematic here, and I suppose that "reset" is a bit awkward, too. In git, a "revert" means you are creating a new commit that is the reverse of the commit you want to undo. The two commits exist and effectively cancel each other out. The danger here is potentially thinking "git reset" will revert a committed and pushed change (sometimes people push early). In general, this is probably not what you intend. "git reset" moves branch pointers around. So when you "git reset HEAD^", you are really saying you want to move your current branch and HEAD (the thing that indicates where you are in the tree) to the prior commit. The current commit still exists but can be ignored. Speculation now, but I think it is right... This same understanding applies to the "unstaging". The staging area is another tree node, and when you say "git reset HEAD" on the staged file, you are moving it back into the HEAD state. One note on unstaging and other resetting... You can reset --soft or --hard. --soft (default) means that you want to dirty up your directory with the differences between the file's current revision and the reset revision. This is useful if you are cleaning up an unpublished branch (using reset to undo). "git reset" could be called "git move-my-branch-tag" and make more sense.
  - cpeterso 15y ago
    btw, the term "revert" has a pretty standard usage in most version control software, including Subversion, Mercurial, Perforce, Bazaar, Darcs, Monotone, Fossil, and AccuRev. Why did git not only invent a new term for discarding uncommitted changes, but reuse "revert" to mean something different?
    - Xurinos 15y ago
      Good question for the devs. "git apply-reverse-patch" was probably too long for a fairly common operation? I suppose when you are trailblazing with a new paradigm, you are allowed to redefine things. I don't let those kinds of things bother me, personally; I just adapt my thinking to the new thing I am learning. Helps me to learn new languages easier.

by sofal 15y ago

cpeterso 15y ago

> Unlike many tools, it is easier to understand the internals of git than the externals. But why should that be? For example, the git docs use different terms for the same thing (e.g. cache, index, stage). Also, the git tools overload the same command for different purposes (e.g. git add tracks new files or stages pending changes from existing files; git reset can unstage pending changes or revert committed changes). These are different functional procedures that happen to share implementation details.

Xurinos 15y ago
Don't use "git reset" to revert committed changes. Well... do, but be careful... The word "revert" is problematic here, and I suppose that "reset" is a bit awkward, too. In git, a "revert" means you are creating a new commit that is the reverse of the commit you want to undo. The two commits exist and effectively cancel each other out. The danger here is potentially thinking "git reset" will revert a committed and pushed change (sometimes people push early). In general, this is probably not what you intend. "git reset" moves branch pointers around. So when you "git reset HEAD^", you are really saying you want to move your current branch and HEAD (the thing that indicates where you are in the tree) to the prior commit. The current commit still exists but can be ignored. Speculation now, but I think it is right... This same understanding applies to the "unstaging". The staging area is another tree node, and when you say "git reset HEAD" on the staged file, you are moving it back into the HEAD state. One note on unstaging and other resetting... You can reset --soft or --hard. --soft (default) means that you want to dirty up your directory with the differences between the file's current revision and the reset revision. This is useful if you are cleaning up an unpublished branch (using reset to undo). "git reset" could be called "git move-my-branch-tag" and make more sense.
- cpeterso 15y ago
  btw, the term "revert" has a pretty standard usage in most version control software, including Subversion, Mercurial, Perforce, Bazaar, Darcs, Monotone, Fossil, and AccuRev. Why did git not only invent a new term for discarding uncommitted changes, but reuse "revert" to mean something different?
  - Xurinos 15y ago
    Good question for the devs. "git apply-reverse-patch" was probably too long for a fairly common operation? I suppose when you are trailblazing with a new paradigm, you are allowed to redefine things. I don't let those kinds of things bother me, personally; I just adapt my thinking to the new thing I am learning. Helps me to learn new languages easier.