There are two Free Software packages that many Free Software people love to hate: Cygwin and Subversion.
Cygwin is a Unix-like environment on Windows. It gives the user a shell, and it’s possible to install there Perl, Python, Ruby, GNU make, gcc, vim and many other familiar tools from the GNU world. It’s even possible to run X windows using it.
I mostly use it for running Perl on Windows. There are two other major versions of Perl for Windows: ActiveState and Strawberry. Every now and then i try using them and i get immediately frustrated: from my experience, Cygwin is much more stable and predictable. Failure to install a CPAN module on Cygwin is much more rare than on ActiveState and Strawberry. Maybe i install the wrong modules, but for modules that i need Cygwin did the job better.
Cygwin is not without problems. But all too often it does the job more readily than ActiveState, Strawberry and GNU/Linux. Nevertheless, Free Software people tend to call me names, when i tell them that i use Cygwin. “You should expect problems when you run an emulator instead of running real Linux!”, they say. Well, what do you know – sometimes, i have to run Windows, that’s a fact of life, and there are stupid problems with Linux, too.
Another stupid holy war in the Free Software community is Git vs. Subversion (SVN in short). Both are source code management (SCM) systems. The “cool” Free Software people say that git is better, because it git lets you create your own repositories, because git is faster, because git is easier.
I can see the principal advantage in having a local repository, which is the way git works. I can work offline and make as many commits as i like. In SVN i need to go online for every commit. But that, in practice, is the only disadvantage that SVN has. People say that SVN sucks at branching and merging. They like to quote Linus Torvalds: “Did you ever try to merge using SVN? Did you enjoy the experience?” Well, i have news for them: I tried branching and merging using Perforce, Mercurial, ClearCase, SVN and git – and i didn’t enjoy the experience in any of them. So git also sucks at branching and merging, but the difference is that with git i lost data, too. Every single time i tried to branch and merge using git, i cursed the hell out of it, copied the files i wanted to change to a backup directory, deleted the repository, recreated it, and did the merge manually. Every single time.
Besides, every time i try to use git, i feel like a fucking scientologist, forced to look up every single word in the help files: how the hell am i supposed to remember the difference between “pull” and “fetch” or between “branch”, “clone” and “checkout”? To understand what “fetch” is, i need to understand what the fuck “head”, “tag”, “object” and “ref” are. Go on and tell me that i should sit down and learn git properly, but i didn’t have to sit down and learn SVN. It just worked without forcing me to understand things.
Call me stupid and old-fashioned, but SVN didn’t give me a headache. Ever.
So, cool kids, go on, keep being cool, keep telling people that Cygwin and SVN suck. But every now and then do a reality check, please. You find it fun to use git? Great. Just don’t force it on other people.
To the developers of Cygwin and SVN i want to say: Thank you. You deserve far more appreciation than you get.
Aharoni in Unicode 
Hmmm, there may be a few simple things you mislearned or didn’t pick up when you first started using git. My guess is that once you get familiar with a few simple commands, git will make a lot more sense.
Here’s the nickel tour, with the usual “except”s and “unless”es and “by default”s elided for simplicity :)
“commit” is both a noun and a verb. As a noun, it represents a snapshot of your source code at one instant in time. As a verb, it means to create such a snapshot. In particular, every commit except the initial one has one or more parents. By tracing backwards from your current commit, down through its parents, you can get back to the initial commit in the repository.
“git clone” creates a new repository by copying an already existing (“origin”) repo. You’ll typically use it once per machine per project. (If you’re starting your own repo, use git-init instead.)
“git fetch” updates your current repo’s database from its origin repo’s database. It doesn’t change any files in your working tree (aka your source code files), nor does it change your current repo’s idea of where any branch is.
For merging, consider one simple case first. If you’re currently on branch “master”, then “git merge origin/master” will integrate your origin repo’s idea of what “master” is with your current repo’s idea of what “master” is. If you haven’t committed any changes, that’ll be a “fast-forward” in which your current repo is simply brought up to date. If you have committed changes to your local version, git will do a textual merge (in which you may have to resolve textual conflicts) and then it will create a new commit with two parents representing both sides (and that’s called a “merge commit”).
“git pull” does exactly two things: “git fetch”, to get the latest info from your origin’s database, and a “git merge origin/master” (if you’re on branch “master”). That’s all. Really. If you understand fetch and merge, then you understand pull.
To create a new branch, “git checkout -b newbranch”, which will also switch to it. This only creates it on your local repo! The origin repo doesn’t know about it until you push it up to the origin.
To switch to an existing branch, “git checkout existingbranch”.
“git branch” itself isn’t terribly useful, it’s mostly used for informative purposes. “git branch newbranch” will do the same as “git checkout -b newbranch” except not switch to it, but most people don’t need to do that very often.
And to push your current branch up to the origin repo, “git push”, or more explicitly, “git push origin currentbranch”. For best results, “git pull” first and resolve any conflicts.
That’s the basics. There’s a lot more but I bet that gets you started. Try browsing github, pick a small project, clone it, and play around with branching and merging.
The single best thing you can do to learn git more quickly is to get a graphical viewer working. Use it read-only, don’t try to commit from it. Use the command line to branch, commit, and merge, then refresh your view in whatever graphical viewer you’re using. Things will make a lot more sense, a lot more quickly. Take the 90 seconds to figure out how to get gitk (or whatever) to work on your system, and use it obsessively. Trust me on this one, it really helps.
Seriously, give it a try. Within a month, the beauty of git’s directed graph of commits will really hit you and you’ll wonder how the heck you put up with svn forcing its ugly steampunk ass-backwards model of branching and merging down your throat.
(And feel free to email me if you have questions, git is one of the few things I don’t mind evangelizing :)
First, thank you very much for taking the time the write this comment. I very seriously appreciate it and i shall probably use it as a cheatsheet the next time i’m forced to send a patch using git.
But there’s something important that you need to understand: I am grumbling not so much about git, but mostly about the attitude of people who love git – or any other program – so much that they can’t stop bashing its competitors and the people who use them. Well, fuck it, i’ve had enough: I refuse to be shamed for using a Free Software (!) program that gets my job done and gets it done well.
There definitely is a thing that you misread: Don’t tell me to learn. I love learning. I just don’t see the need to learn to use a hard tool, when i already have an easy tool that does the job i need and does it well.
I need to get some source files, edit them and save them to the repo or prepare a patch and send it to the repo owner. Every now and then i need to add, rename or delete a file. Period. SVN does these things well and i didn’t need to learn anything to accomplish them: for six easy operations there are six easy commands. SVN’s inner workings may be old-fashioned, but – surprise! – SVN users very happily don’t give a fuck about it.
Read the first page of The Camel Book: “so-called industrial-strength languages make it equally difficult to do almost everything”. That’s exactly what git is – everything is difficult there. (Ironically enough, Perl’s source is kept in git; I hope that perl-porters are happy about it. I am not, because for me it makes sending patches nearly impossible.)
Well, here’s another surprise then: I cloned a small project today, fixed a typo in a translation to Hebrew and pushed this fix. After a few hours i fixed another typo, and then i recalled that i forgot to update my repo. After spending a few stressful minutes trying to understand whether i should pull or fetch, i ran one of them – don’t remember which – and saw that i have conflict. I resolved the conflict – or so i understood from the messages – committed, and pushed. The repo owner said that it had an error. I tried again and he, again, said that there was an error and suggested sending the corrected lines by email.
I still wanted to give it a try, so i deleted the repo, re-forked, re-cloned, re-fixed the lines and re-pushed. This time it worked. But notice: I had to clone the project twice per machine just to send a patch. It happens to me every time i try to send a patch using git, and it never happened with SVN.
You see? – That’s exactly the thing i’m talking about. SVN’s branching and merging may be old-fashioned, but it’s so rarely used, that nobody gives a damn about it. It’s rarely used, because from what i’ve seen all the programmers who use any kind of SCM, including git, suffer from branching, merging and rebasing using it. Because merging, with any SCM, boils down to going over many lines of diffs. IRL programmers know that if they bother with the merging capabilities of their SCM server, they will quite likely lose time, data and their mind. They also know that if they just make a copy of the files they’re changing, make the needed changes and run diff, they’ll get the same effect without the above-mentioned damage to their files and their mental health.
Some smartasses like branching and merging anyway. Lovely, but it’s not a good reason to make updating and committing hard for the normal people.
And yet you think that it’s so important to curse the people who programmed SVN and the people who use it.
Yet again: I may sound gruff, but i really do appreciate the time you took to write your comment. I’ve been trying to seriously learn this sexy piece of software called git for the last three years or so and thought that i’m stupid. Today i decided to stop thinking that i’m stupid.
If you know git well, love it, and want to evangelize it, start by making its man pages readable to steampunk SVN-using muggles. That’s what man pages are there for. Just run `git help fetch’ and imagine for a minute that you don’t know git; would you understand a word of it?
Well, no, you can’t learn git from manpages, but that’s true for any unix program of any complexity. Manpages are references for people who already know how to use unix commands.
Easy branching and merging are essential for large software projects, and the only reason anyone thinks otherwise is if they’ve never experienced easy branching and merging. It’s not for smartasses, it’s for people who work on more than one thing at a time and don’t write everything perfectly the first time. I’ll stipulate that nobody branches and merges in svn: that’s proof it’s broken.
Calling svn “steampunk” is letting it off easy. Not putting up with inferior systems is a programming tradition, and for good reason, it helps us avoid inferior systems! Try Joel Spolsky’s introduction at http://hginit.com/top/00.html for a properly scathing explanation. (“I have been very careful not to explain things in terms of Subversion, because there is just no reason to cause any more brain damage.”) Joel advocates Mercurial, which isn’t too dissimilar from git.
Git’s hard to learn, yes. About 75% of its difficulty is because we all mislearned what version control was by using broken systems for far too long. The other 25% is just that version control is hard, and git doesn’t dumb it down to make it look easy.
*You* are not dumb. There’s nothing wrong with you for not getting it the first time around. You just haven’t found a good git tutorial yet. I can’t make you do anything, but I can suggest that if you want to use version control more productively, my experience has been that git is a huge, huge win. Feel free to ignore me if you want.
Unfortunately, I haven’t found a really, really good git tutorial myself. You can google for one as well as I can, I guess. Maybe I’ll try writing one myself someday…
Thanks for keeping cool despite my annoyance and foul language :)
No, it’s nothing but offensive. If git lovers were offending a proprietary commercial product, it wouldn’t be as bad, but offending a Free Software package, its users and its developers, at least some of whom are volunteers, is just plain rude. You are not saving the world this way, you are just creating antagonism.
Oh, i did. I’m in this industry for 12 years now. I’ve been in large projects of over 100 developers. They either used cp and diff and got on with their lives or used the company-sanctioned SCM (mostly Perforce and ClearCase, a little Mercurial) and climbed on the walls.
I tried to introduce git to one of the companies in which i worked. I worked with it for a few days, then tried branching… and lost a few days’ work. That was not a win. After that the company very happily used SVN. The happiest developers i’ve seen in my career were SVN users.
I just haven’t yet seen any tangible proof that git’s learning curve is worth it, despite the many promises.
I did, many times. I usually come upon very nicely-designed sites, who seem to have been made by people who know CSS well (or have friends who do), but who assume that what they learned about git by some unknown magic is known to all their readers, too. Hey, i do admit that github is sexy. It just gives me a headache every time i try to send a patch.
And if there is no good tutorial, how did you learn it? I suppose that you do see the contradiction here…
… And that would be much, much more productive than calling fellow developers’ work ass-backwards steampunk.
offending a Free Software package, its users and its developers, at least some of whom are volunteers, is just plain rude. You are not saving the world this way, you are just creating antagonism.
I can do both at once ;)
And if there is no good tutorial, how did you learn it?
It took a while!
FWIW, it is actually pretty hard to actually lose work in git, unless you use -f switches (on various commands) or the –hard switch on git-reset.
In almost all other cases your work will be preserved somewhere, in some form. That said, though, recovering your work from a (series of) erroneous commands is often well beyond a git newbie’s skills.
If you branch and merge in the ordinary, correct way — and don’t try to turn git into something it’s not by cp’ing files from one branch to another, or resolving conflicts by overwriting entire files — I think it’s almost impossible to actually lose work. Even in a worst-case scenario, if you rewind a branch and there are no more branches or tags that point to some commits, they are still in your git database, just “unreachable” by ordinary means.
For example, here’s me creating a new git repo with two commits. Then a “git reset –hard HEAD^” forces my master branch to stop pointing to the 2nd commit and point instead to the 1st. (“HEAD” is an alias that points to the current commit; “HEAD^” points to its parent.)
At that point “git log” only shows me the first commit, so it looks like my 2nd commit is lost.
But HEAD@{1} always points to the commit that HEAD was pointing to “previously,” in other words, wherever it was pointing before it was moved to point to what it’s pointing to now. Which makes it work as kind of an undo feature. Even though no branch or tag is pointing to my 2nd commit, I can “git reset –hard HEAD@{1}”. That effectively undoes my previous command that moved where the branch points (i.e. the previous “git reset”).
(More info on the @{n} syntax is in “git rev-parse” under “Specifying Revisions.”)
08/06 12:36 jmccarthyMBP:~$ mkdir foo 08/06 12:36 jmccarthyMBP:~$ cd foo 08/06 12:36 jmccarthyMBP:~/foo$ git init . Initialized empty Git repository in /Users/jamie/foo/.git/ 08/06 12:36 (master #) jmccarthyMBP:~/foo$ git config --global user.name 'Jamie McCarthy' 08/06 12:37 (master #) jmccarthyMBP:~/foo$ git config --global user.email jamie@mccarthy.vg 08/06 12:37 (master #) jmccarthyMBP:~/foo$ echo 'file version 1' > myfile 08/06 12:37 (master #%) jmccarthyMBP:~/foo$ git add myfile 08/06 12:37 (master #) jmccarthyMBP:~/foo$ git commit -m 'commit 1' [master (root-commit) 18a0a00] commit 1 1 files changed, 1 insertions(+), 0 deletions(-) create mode 100644 myfile 08/06 12:37 (master) jmccarthyMBP:~/foo$ echo 'file version 2' > myfile 08/06 12:37 (master *) jmccarthyMBP:~/foo$ git commit -a -m 'commit 2' [master 0f4c702] commit 2 1 files changed, 1 insertions(+), 1 deletions(-) 08/06 12:37 (master) jmccarthyMBP:~/foo$ git reset --hard HEAD^ HEAD is now at 18a0a00 commit 1 08/06 12:38 (master) jmccarthyMBP:~/foo$ cat myfile file version 1 08/06 12:38 (master) jmccarthyMBP:~/foo$ git log commit 18a0a001b7d23b8bd0952c9ff5e8f5b762bcd508 Author: Jamie McCarthy Date: Fri Aug 6 12:37:34 2010 -0400 commit 1 08/06 12:39 (master) jmccarthyMBP:~/foo$ git log HEAD@{1} commit 0f4c7026d29eca46fd3b9fc168209ede0d3b5047 Author: Jamie McCarthy Date: Fri Aug 6 12:37:55 2010 -0400 commit 2 commit 18a0a001b7d23b8bd0952c9ff5e8f5b762bcd508 Author: Jamie McCarthy Date: Fri Aug 6 12:37:34 2010 -0400 commit 1 08/06 12:39 (master) jmccarthyMBP:~/foo$ git reset --hard HEAD@{1} HEAD is now at 0f4c702 commit 2 08/06 12:39 (master) jmccarthyMBP:~/foo$ git log commit 0f4c7026d29eca46fd3b9fc168209ede0d3b5047 Author: Jamie McCarthy Date: Fri Aug 6 12:37:55 2010 -0400 commit 2 commit 18a0a001b7d23b8bd0952c9ff5e8f5b762bcd508 Author: Jamie McCarthy Date: Fri Aug 6 12:37:34 2010 -0400 commit 1 08/06 12:39 (master) jmccarthyMBP:~/foo$ cat myfile file version 2I don’t claim this would have solved your lost-data problem, but hopefully it illustrates that git tries really hard to give you the tools to recover from unwanted changes.
You know, it would be much easier to help you out if you were a bit more specific on the incidents.
Then: Merging generally works pretty well (in svn: at the basic level). Of course there are conflicts when you and I changed the same part of a file, but that can happen just as well during an ‘svn update’ into a dirty sandbox (and there is no way to revert that back to the state before the update).
And it’s not just me. I see many people happily doing merges and relying on the results, and a very few that say that it doesn’t work at all for them.
What absolutely kills merging is gratuitous reformatting of the sources, and that unfortunately includes changing the line end characters in the file. This is a major nuisance when working with windows people. :-(
I have used both svn and git extensively, and when I have to use svn it’s like I’m giving up half my programming tools.
I know plenty of really smart people, good programmers, who are happy with svn and don’t see any point in learning what I’ll readily admit is a much more complicated tool.
All I’ll ask is to have mercy on the git folks. They’re not in love with git because it’s cool. They don’t dislike svn because it’s old. They love git because it’s more powerful, even at the little things, than svn.
There are things to dislike about git. I love what you say about merging: it’s just plain hard in any system, and I found it the most difficult thing to learn about git. But (and you know what I’m going to say here), it’s better in git than in svn.
I’m not here to advocate for git. I’m here to say that when git people try to convert the svn users of the world, it’s not because svn is not cool. It’s because it’s hard to watch people live without something that could make their lives easier. I work with people who use svn every day and see them suffering while they work and they don’t even realize it. “Cool” doesn’t have anything to do with it.
If branching and merging with git and hg was too hard, give darcs a try, it’s much simpler: since it is based on patches, there is no “merge” command, just pull and push.
Darcs is certainly a nice system if you look for good cherry-picking functionality, but it does not scale up well. If you have many long-lived parallel branches then time needed to track patch dependencies grow exponentially. Also there are some other reasons why excessive cherry-picking may be objectionable. No VCS can automatically determine semantic dependencies between patches, and relying on syntactic dependencies may screw up you badly when you are dealing with complex stuff.
The model used by Git/Hg is more predictable and more reliable if it is used properly. It is always easy to understand what Git does during merge. There is no magic behind your back as it happens with some other systems that tries to be “smart”. But Git requires some discipline and knowledge to use it properly. I suggest you read “man gitworkflows” first, which describes how to organize your work properly.
Well the topic here is VCS hardness, so darcs seems an adequate answer to me. As for your comments, are you talking from experience? Performance-wise, Darcs has improved a lot: http://is.gd/egyal
I guess we should also include cherry-picking between long-lived branches into our benchmarks to measure and improve this aspect.
I guess, Darcs 2 has improved in this regard, but I heard it still has some corner cases. But even with all scalability issues being resolved (and I doubt it is realistic), I believe that cherry-picking is the wrong way to go, especially for big projects, because any tool can only detect syntactic dependencies between patches. So you may not notice that you need some other patches. However, if you have a branch implementing some feature, then it is clear what changes should be merged to add this feature.
IOW, patches cannot be good or bad, because you cannot test any patch without applying it to some revision. And when you can apply it to one revision, and everything may work fine, but then you apply the same patch to another revision (without any conflict) and suddenly your program fails. This unlikely to happen in simple cases, but it happens quite often in big projects with many subtle dependencies.
No system can merge fully automatically, but with Git it is easier if you understand what you are doing. Besides, it is highly unlikely that you really lost any committed data. Erroneous actions do not destroy any earlier committed data immediately. So, most likely, you just did not know where to look…
BTW, I have looked at the Git repository, and it contains more than five thousands merges made by Junio Hamano alone, and this number does not include the number of merges made on the ‘pu’ branch that have been discarded. (Every few days, Junio rewinds the ‘pu’ branch, so he has to re-merge dozens branches queued on it.) So, merging is not a problem in Git if you know what you are doing…
If you are serious about learning Git then you certainly should put some efforts to learn at least some basic concepts without that there will be no progress. And your argument that you didn’t have to sit and learn SVN does not mean that SVN is easier than Git. It is like saying that I did not have to sit down and learn my native language, so it must be something wrong with other languages if I cannot acquire them easily now as learned my native language as a child.
While this analogue is not perfect, the point is that your previous experience always influence on how we perceive other things. Your main mistake is that you assume that Git is similar to SVN but with different command names. But this is like if you tried to write in English as if it were Russian with English words instead of Russian ones. I don’t think this kind of writing would get you far. Similarly, as you cannot ignore grammar and phonetics when learning another language, you cannot really use Git without understanding basic Git concepts. No Git cheatsheet can help you here. In fact, those cheatsheets are more distraction from real learning than help.
As to your skepticism about Git, it is a rather common initial reaction among many long-time SVN users. For instance, Joel Spolsky and Jeff Atwood derided DVCS in their Stack Overflow podcast, in January, 2009. One year later, they completely changed their opinion. See “Distributed Version Control is here to stay, baby” by Joel Spolsky.
Now, if you are happy with SVN then maybe you should stay with it, because Git will not magically solve your problems. Git can help you only if you have a desire to improve your development process, and take advantage of more powerful tools. If you are happy with things as they are then why to bother?
I don’t think that is particular difficult to learn, but its model is very different from what you used to with SVN. SVN has been clearly modeled after CVS, and SVN developers tried to fix common complains of CVS users, such as lack of atomic commits, or that the rename operation does not preserve history, etc. Apparently, not much thoughts had been put in how to merge branches, because CVS users tried to avoid branching and merging as much as possible. In CVS, merging was considered an advanced technique that only a guru can do. So, initially SVN provided only slightly better interface to essentially same functionality, because no SVN developer could imagine that a repository may contain thousands branches, and that those branches could be developed for many months and then merged to “trunk”. So, the SVN model appeared to be very logical to what they tried to achieve at that time. Basically, it is similar a versioning file system except that you have to explicitly commit your changes, and those changes are committed as a single ChangeSet. Thus the primary underlying structure for SVN is a directed acyclic graph (DAG) representing a file system. This structure works fine as long you do not care about merges.
On the other hand, one of primary concerns for Git was to have good merging, because without good merging, a DVCS simply is useless. So, the primary structure of Git is a DAG representing the repository history. Each commit is just a node in this graph. Tags and branches are references to some nodes(commits). Each commit is a full snapshot of your working tree with a commit comment and other attributes attached to it (author, date, parent commits). The difference between tags and branches is that the latter can advance when a new commit is created. A normal commit has just one parent, but a merge operation creates a commit that has two or more parents. The default merge strategy in Git is 3-way merge, which relies on common ancestor. So, just by looking at the history graph, you can see what is going to be merged. Thus when you have a conflict, you can clearly see what caused it and decide how to resolve it.
Obviously, not everyone uses a lot of branches and merges, but the reason why I spoke so much about it is that in many ways it determines the Git model. There are many other features in Git, and I don’t think anyone uses all of them regularly, but when you need something, it is nice to have it. Personally, I decided to give Git a try because of “rebase”. It was my favorite feature for some time. Only later I learned how to use branches correctly, and what it is the right balance between using rebase and merge.
I think git is great and I think svn is great.
git sucks on storing our word documents, excel sheets and other binary data, because you have to lock them before editing them(anyone svn:needs-lock ?)
For pure sourcecode hacking git is great, however people other than developers have started using subversion and for them subversion is the solution of all their needs (and they do not merge at all!).
Subversion is the poor mans VCS and its versatility on plattforms (yes windows is a platform, too! And no, cygwin is not a replacement for delivering a working system. Cygwin application may work, but they are not windows applications)
And 1 thing regarding ease of use:
Subversion client has 32 commands you will barely need more than 10 of it.
Git has displayed in its help 21 “most commonly used” commands.
on my portable git installation I find 114 git-xxx.exe files
Do not tell me git is easier to understand. It is much more powerful and its underlying mechanic is simpler, but to get a workflow up and running you need much more knowledge!
Last words:
I think git-svn is a great solution to reach hands. I love working offline on my svn repos and I love to lock openoffice docs for working on them.
Peace On Earth
“To understand what “fetch” is, i need to understand what the fuck “head”, “tag”, “object” and “ref” are.”
Bad news: if you want to drive a car, you need to understand what the fuck “break”, “transmission”, “gasoline” and “seatbelt” are.
“brake” :)
“break” is what happens when to builds when developers merge branches, regardless of the VCS :)
But to continue the analogy:
To use SVN, you need to understand “brake”, “transmission”, “gasoline” and “seatbelt”.
To use git, you need to understand “slave cylinder”, “idler jet”, “hill holder” and “tappet head”.
Simples.