gitantilover wrote the following:
(fast cloning it only needed once, so it’s a joke to use it as advantage; fast committing yes, but how often do you use this? You should wirte a complete module or an task before checking in)

I think gitantlover is using old CVS/SVN terminology. You should NOT write a complete module or task before checking it in in git. Think of local git check-ins more as saving your file. Every day, multiple times, you save your file in a CVS/SVN project. If you want to get back to the version you had 2 hours ago that you did not check in, what do you do? You have to save those files manually (or have something like Eclipse that will store these for you). Some important save-points would be ‘local commits’ with git.

The git push is what you do when you would do a normal commit in CVS/SVN.

The same issues happen if your machine crashes in either git or CVS/SVN – you lose everything since your last push (git) or commit (CVS/SVN) unless you have local backups.

Also, don’t forget the bit about letting a user choose “all stories”, and then disregarding that choice. Over and over again.

Andrew, this might be true if Git was the only DVCS or if all of them were equally hard to use. Thing is, they aren’t, so the argument “it’s your fault, not Git’s” doesn’t hold water.
Someone wrote that most people who think they like Git actually like DVCS, not Git specifically. The workflow you describe works in any of them. There aren’t many who argue that this is a bad thing. Actually, most quite like it. But they argue that Git is a bad thing – compared to the other DVCS.

I happen to agree with them, but I don’t hate Git. I know it’s kind of unpopular to not absolutely love or absolutely hate stuff, but really, I just get along a lot better with Bazaar and Mercurial.

One of my favourite parts is that committing isn’t committing to another device (as stated in the last post there). Basically, after every change I make that completes a piece of the idea (branch) I am working on and has my app in a stable state, I commit. That way, if I make changes to stuff I have just changed and back myself into an undoable corner, I can revert to the point I was at before I moved on to this next step. When it comes time to push to the central repo, I can squash all my little commits into one nice succinct one. Not sure how anyone can argue that is a bad thing but I’m sure some genius who has just decided they hate Git will find a way.

And to make a comment about people making fun Git claiming it has no central repo, of course there is always a central repo. What Git does is allow ANY copy of the repo to be the central one as a clone gives you the entire history of the project (all deltas in ONE .git directory). If the one your project has decided is the central one somehow gets corrupt or deleted or whatever (github gets hacked, perhaps), you can copy over anyone’s repo who is working on it and use it as the central one. In other words, you have as many back-ups as you do people working on the project. EFFICIENT!

The only true negative I have read here is that you can’t resume a clone. This is true and is totally lame BUT you can always just grab the repo by other means (like S/FTP) and link up to a remote afterwards. It’s a work-around, but it works. Oh yeah, it’s also a negative that you have to put in some time to learn the technology therefore receiving no instant gratification. *sideways glance*