Hacker News Reader

Comment by eknkc | Hacker News Reader

Used both SVN and GIT on different types of projects. Gotta admit, it's been a little harder to get used to GIT. It has a more complex interface and ways of doing things.

However, it feels like comparing SVN to GIT is like comparing horses to automobiles at this point.. Yes, a horse can heal minor damages without a mechanic, your car can't. And it can swim if need arises, good luck with a car on that.

Woudn't choose a horse for anything serious though. Maybe for fun and sports.

View on HN

Nitpick: It's just Git, it's not an acronym.

I agree git has a more complex interface - I think I've read it described as "not quite user-hostile, but only expert-friendly", which I think fits.

That said, I think the model of how commits work is far more intuitive than anything else I've come across. A commit is just a diff and a pointer to the commit that came before it, and a branch is just a pointer to a particular commit.

Technically, a commit is a _snapshot_, not a diff.

Nitpick: A commit is not a diff, it is the entire tree. Any diffs you see are computed, not stored.

You can export a commit as a diff+pointer-to-prev-commit, but when git imports it, it gets turned back into a full tree.

That's true. I simplified for the sake of not delving too far into the details, because it makes sense at the smaller level. It's also true that a commit isn't always just one pointer to the commit that came before it, in a merge there are two pointers, from commit_head and merge_head

Used both too, the main reason we are moving away from SVN is the hell created when something deletes a folder outside of SVN. Storing .svn inside every single folder creates a world of pain with web apps that update themselves.

Subversion has had a single .svn directory since version 1.7 (http://subversion.apache.org/docs/release-notes/1.7.html#wc-...), released in October 2011 (http://subversion.apache.org/news.html)

Reply on news.ycombinator.com