git everywhere... (how to compare my stuff to the central repository)

The easiest way to compare your local changes to the central repo is IMHO "git diff origin/master"
This also includes everything you haven't committed yet.

FWIW, the best book out there right now happens to be free and online: http://progit.org/book/

Another great read is the "Git Parable:" http://tom.preston-werner.com/2009/05/19/the-git-parable.html

After the parable and the first 3-4 chapters of Pro Git - an evening read, overall - most people should be pretty fit with git.

Just stop trying to use SVN as your frame of reference .

I created a 'What on earth does this mean?' page on techbase last night where we can collect confusing messages etc. like those you're seeing in one place. Hopefully we can even get some answers as to what they mean.

http://techbase.kde.org/Development/Tutorials/Git/decoding-git

Sounds like you've got everything at once. And I agree there are many confusing tutorials out there. This prompted me to start writing something as well ( http://codingdomain.com/git/ - it is not finished yet ). The mental model of DVCS are different from SVN. Perhaps it's better not to compare both.

To give some answers to your blog:
* `git add` can be considered as an alias for `git stage`. It adds files to the "staging area" (the place where you prepare your next commit).
* to exchange commits with a remote repository, it needs to be added to your "git remote" list (sort of bookmarks).
* then you can do "git fetch" to retrieve any commits you don't have. (they live side-by-side because the SHA1 identifiers differ)
* the remote commit chains appear as a second branch, which you can merge (connect both ends) or rebase (place your local commits on top).
* to get an overview of where things are, you can use `gitk` or: `git log --graph --all --decorate`

I think it helps when you are learning git to use some visual tools: they give you a more high-level view. Git itself comes with at least two useful ones: "gitk" to browse your git history and "git gui" to create/edit commits and push changes. They are a bit ugly (tcl/tk!) but works quite well and are damn fast. I personally do most of my commits with "git gui". Note that they must be started from your working copy dir.

If you want something more console-oriented, then make sure you install tig, an ncurses based repository browser ( http://jonas.nitro.dk/tig/ ).

Remote branches is what I find the most complex to handle. That is why I like to use grb ( http://grb.rubyforge.org/ ) for this.

Finally here are a few aliases I set up which can be handy when coming from an svn background. Copy these lines to your $HOME/.gitconfig:

[alias]
up = pull --rebase
st = status
ci = commit

For extra fancyness, you may want these as well:

[color]
branch = auto
diff = auto
status = auto

> is it really that complicated, doing like one of the most basic things ?

Yes, it's an entry barrier and definitive not a small one. I would say its harder then learning cmake

I think the real trick to learning git (or any other DVCS for the first time), is not to assume that you can figure it out as you go. Moving from CVS to SVN, that's a pretty safe assumption, but with git, you'll just waste your time.

Invest an hour or two and read through a few tutorials. Once you grasp the basic concepts behind it, things start to become a lot clearer. There's no question that you'll still frequently hit roadblocks and have to resort to Google, but at least you'll have a base of knowledge to build on.

git diff HEAD..[remote-name]/[remote-branch]
e.g.
git diff HEAD..origin/master

There is a lot of good git documentation out there -- it help to take an hour to learn the basic concepts. Makes you much more productive in the long run. For instance, the tutorial is a place to get a feel for how to use it.

http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html

I still like DSCMs much more than SVN & Co. I use mercurial but git is not much different (except, what is this "stash"?). When I want to see what I've changed since my last pull I just fire up hgtk log (or gitk) and look what was the last rev that wasn't committed by me. Then I could do a "hg bundle --base 6047 mychanges.hg". Then I send the bundle to a user who can just pull it, which is exactly the same as if he would have pulled from my repo! That is a cool thing.

Other things I like about hg (which I think most apply to git as well):

• Full offline work.
• True open source because forks and cross fork merges are easy.
• You can create a repo on your usb stick and never lose changes you made to your homework at an university computer again.
• You can run a webserver from which people can pull (and if you want to which people can push) through "hg serve".
• Only a tiny cgi script is needed to put a remote hg repository into your universities webspace to which your colleges can push (using e.g. .htaccess for authentication). I always thought that our university should provide a VCS server to us, not just a LAMP+cgi webspace. This way *I* could fix that.
• The included web interface can paint a tree using the canvas element.
• ssh access and installed hg at the ssh server (or I guess even a nfs mount) also suffices. No need to run a webserver.

Things that only apply to hg (AFAIK):

• Nice python API.
• Extensible through python.
• Pure python fallback if no native modules (for performance) are available and thus a lot of platforms are supported.
• TortoiseHg (Windows/*nix+GNOME/OS X) or just the hgtk command from it (yes, its gtk but who cares? it is a nice interface).
• NetBeans has built-in hg support.

Oh and I think its "git pull --rebase". At least that's what I do when I linearize my history when I want to push changes to amarok. But the hg philosophy is to preserve and not change history. Ok, linearistaion of only local changes should no make a big problem, but jsut in principle history should not change. After all only Guido has a time machine.

Another thing I like about hg is that pull does NOT update the working copy. You can pull and before you update to tip, another head or whatever you can use hgtk to look at what has changed and decide to which rev you really want to update (but if you like you can also do "hg pull --rebase -u" in order to pull, rebase and update at the same time). Oh and hg does not need repacks.

But if you really do not want to use git: git has a pretty good svn bridge. This means it can push/pull to/from an svn server but also act as an svn server itself. I think this git does better than hg.