> Once tried to use it for some kernel patch and found it to be very confusing.
May I ask why? git is a different VCS, but it isn't any more difficult to learn than CVS. Once you get used to the idea that the files you are working on are not the same as the files in the repository and must be committed, it is all you need. git has a considerable number of advanced features, but you don't have to use them if you don't want to.
A typical usage scenario is not different at all. For example, suppose you want to change src/dosbox.cpp to fix some bug. In CVS you would do:
cvs update
edit src/dosbox.cpp
cvs diff src/dosbox.cpp
cvs commit -m "Fixed bug 33482838" src/dosbox.cpp
Updating your sources, editing them, doing code review, and committing. In git, you'd do:
git pull
edit src/dosbox.cpp
git diff
git commit -a -m "Fixed bug 33482838"
git push
The steps are basically the same, with two differences: git versions by checkin, not by file, and you upload to the common repository manually.
These differences are both good things. Versioning by checkin ensures that everyone has the same tree you did when they get your fix and that everyone can see the entirety of what you did. In cvs, you can't do that; you can't see a checkin. You can only see file versions.
For example, yesterday, you made a commit "patch 1982117 Some minor bugs in the debugger, by etillate". I can go to the Sourceforge CVS browser and notice that src/debug/debug.cpp and src/debug/debug_gui.cpp have changed versions recently. I can also see that they both have the same commit message, which tells me that you committed them both in a single checkin. Now I might wonder, were those two files the only ones touched? Was this the most recent commit? If something bad happens due to this checkin, how would you answer these questions if you needed to rollback this commit? In CVS it can not be easily done.
In my git tree, which I have just updated, all I have to do is fire up gitk (the history browser), and I immediately see that yes, that was the most recent commit. I see a list of all files that were committed, and a complete diff of them, which is something you can't get at all in cvs. Furthermore, because of the way git handles content, I can be absolutely certain that if your tree says it is on commit v0.72-178-g358d16d, and my tree is on the same commit, we have exactly the same tree, even if you generate your own git repository from your own CVS sources.
The second difference is that in git you work offline by default. In CVS, if you can't reach your server, you can't commit, so you let work pile up until you finally get a huge commit in. Heaven help you if something breaks on you halfway through. How will you know which of your recent changes broke the code? I had this very problem just yesterday, on one of my projects. I made too many changes and something broke. Because there were several fixes, all touching the same files, I couldn't just reset them ("git checkout file.cpp" reverts changes, "git checkout -f" reverts all changes). I ended up ditching all the changes, making a private branch, and checkpointing each change in turn, which made the work go much smoother.
Another advantage of offline work is speed. All git commands complete instantaneously. There is no delay at all. I remember how long a diff took when I used cvs and it isn't even funny. With git, I can diff instantly all my changes at any time. I can look at history, instantly. And I can back out my changes instantly if I screw up. You have no idea how addicting and convenient this is :)
Finally, working offline, on your private branch, is an enormous advantage to people who make patches. Take the patch by etillate you committed yesterday, for instance. The way he would have had to make it, was to checkout the cvs tree, make changes, and then wait until you got around to committing it. If he wanted to make other changes, he'd either have to let them snowball onto the previous ones, or to checkout another tree to do them in.
In git, he'd get the tree, make changes, commit them (to his repository, which is separate from the mainline repository), send you a diff (instead of "git push", which requires write access to the mainline repository), and keep working. If/when you committed the patch into the mainline, he'd only need to "git pull", merging automatically and transparently. This is how Linus maintains Linux, and this process is one of the more streamlined ones in git, since he has to do it forty times every day.
Anyway, can I send you my git repository of dosbox? The forum says it's too big to attach. You can play with it and see for yourself.
