Hacker News Reader

Comment by roel_v | Hacker News Reader

What are those problems? Why are they less with git? I often make branches with subversion; what goes wrong is keeping track of what features/changesets need to be merged across which branches, plus 'dependencies' of those changesets (changes in previous commits to the branch that add e.g. a class definition that the changesets depends on). Does git improve on that? How?

View on HN

What he really means is that branches are now a part of your daily workflow. You can sync up to head (or wherever you pulled your working copy of the repository from), create a branch, and start working on some feature on that branch, mucking up a hundred files along the way. Now say some some urgent issue comes up that you need to fix immediately -- you can easily go back to the point before you branched, and create a new branch from there on which you can fix the issue. Meanwhile, your previous branch still exists, so when the urgent issue is fixed you can resume where you are working on. Another great thing about branches is say you're working on some feature in a branch and you come to a point where you can implement something multiple ways, but don't know which one will turn out elegant. You can create a new branch from that point in your current branch, and if it doesn't pan out, revert it to where you were.

The kicker with Git is that all these branch operations take on the order of milliseconds because Git stores the entire project history -- all past revisions of files, etc -- locally. Sure, you pay in a bit of disk space, but consequently almost all common operations can be done without hitting the network and are crazy fast. Even when you execute a commit, you're not committing to a server, but to your working copy of the repository. Later, you can push your changes somewhere else and merge accordingly.

Furthermore, git stores the entire project history locally and compressed in such a way that a live git project (checkout+entire history) often takes LESS space than an equivalent live subversion project (checkout * 2, which subversion does for allowing you to diff without having to go to the server).

Obviously, if you add a 1GB random file then delete it, the git entire history will have 1GB more data than an SVN checkout. but usually, it's smaller.

I've switched to using gitsvn exclusively for svn projects I'm involved with since I noticed that -- I save space and have complete project history locally. What more could you ask for?

(p.s: git svn is a better svn client than svn. really)

Here is my favourite drawing illustrating one of the problems with Subversion:

                      |
                      | file p.txt contains "X"
                      |
 +<---(branch)--------+
 |                    |
 * file p.txt renamed |
 | to f/p.txt, which  |
 | contains "X"       |
 |                    * the content of file p.txt is updated to
 |                    | contain "Y"
 |                    |
 |                    |
 +----(merge)-------->+ file p.txt is deleted and file f/p.txt is created
                      | with the content "X"  
                      |
                      | BUT expected/wanted content is: "Y" (or at least a conflict)
                      V

Branches are usable only when a merge is not unnecessarily painful. SVN's lack of ability to track renames is a big pain especially in languages like Java where the filename corresponds to code itself. SVN is capable of leaving the codebase broken after a merge.

Here's an example scenario I described in my blog an year back. http://tuxychandru.blogspot.com/2010/01/how-git-shines-above...

Reply on news.ycombinator.com