Hacker News Reader

Comment by Aqueous | Hacker News Reader

The answer basically amounts to: "Git is harder to understand."

Fortunately that difficulty has a huge payoff that SVN simply can't beat. Git has a superset of SVN's functionality - it can act as a central repository, and can also support any granularity of permissions you wish.

And you can pull in, pull out subtrees using Git using the git subtree module.

View on HN

It is not just about being harder to understand. I would say it is partially self contradicting. First, it teaches you to unlearn the centralized vc. But i am yet to see a commercial git repo which doesn't maintain a central branch. The amount of confusion it puts an average developer into, specially if they are coming from subversion background does eat a lot of energy. I bet the person making the decision to switch to git, didn't foresee that (i didn't). Otherwise, you always would question if it is worth the trouble maintaining the project. Having said that, although there are countless benefits of git, but the one that truly makes it worthwhile in my scenario was the difference in merging capability. SVN needs to go a really long way even to be competitive there.

I work in an SVN shop, so I haven't had much experience with git thus far.

What are the advantages that git has over SVN in merging? I've never had any problems merging while using SVN.

Though it might be a lot to write, but just a small case as an example. If you have two different variables initialized on same line number in svn, it is possible that in merging two different branches (not revisions), svn quietly puts them BOTH in the code which doesn't even produce a compile time error and it takes ages to find out the actual cause. I have actually been through this since we used to have a dpi product whose separately developed branches for different target platforms needed to be merged and it was all svn. At best svn would give you manual conflicts to resolve. With git, the number of conflicts to be resolved by hand is far less. For a general list, take a look at http://stackoverflow.com/questions/2471606/how-and-or-why-is...

Git subtree does not cover the same use case as a subtree checkout in SVN. You need a complete clone to create the subtree repository and to push changes from the subtree repo to the main one.

Exactly! Also imagine the situation when you only were working inside one source folder in a large code base, changed 3-4 files significantly and latter decided to revert back to original ones. It just takes svn revert -r revision in that folder to get back original files. With git you can't get away without having to create subtree first

Wouldn't `git reset --hard <sha-commit>` do that ?

Not an option if the rest of code base is likely different from the original cloned from. For me, this very often has been the case i.e. small changes in like may be 20 files scattered all over the code base just to get my copy run in a specific way debugging an issue.

What's wrong about `git revert <commit-sha>`? It should be just fine, supposing no one changed the mentioned files in the meantime.

Oh, i meant the other 20 files all around the code base have just been changed to get my local setup to work. There is no way (without sub branching) in git to have a lot of modified files, but only wanting to revert the ones actually being worked upon. Core concept was still shallow check out in case of svn

Still not sure what's the case exactly. You mean, kind of partially revert a commit, but only the files in the commit which are in a specific subfolder?

Yeah Exactly. Probably i should have worded more appropriately. But given the fact that most of software developers have to maintain large existing code bases, tailor a specific subsection to achieve a goal and only need to commit just a folder in that sub section

  git checkout -- <file>

This will revert the file back to the the last checked out version.

  git checkout <sha-1> -- <file>

Will revert a file to the state it was in, in that particular sha-1.

Yeah this will definitely do that. Only that mentioning name per file is painful. In large source trees, you often exactly don't know which files have been modified. You just have been following through a debug path making changes where needed. Just having the ability to checkout a folder down the hierarchy is really handy. Git recently added "sparse checkouts" but still they only solve the problem partially

What's wrong with making a local branch? Or remote for that reason... that's precisely what they're there for.

Nothing wrong, just the fact that you cannot latter push ONLY a sub section of code from local branch (while leaving many other changes done in local for local needs) as opposed to svn. This is further mentioned in other comments

Mercurial can do that as well, with "hg revert -r <revision> <directory>".

I must admit i liked mercurial a lot. The simplicity that is underrated (of svn) is found in tons in mercurial. In fact dvcs initially was hard to get my head around conceptually with git. Keep in mind the unlearn part is harder from years of svn. Then i actually read a tutorial on Joel Spolksky's website about mercurial and how FogCreek uses it. That really helped me conceptually with dvcs.

Reply on news.ycombinator.com