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.

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*

As someone who has only ever used CVCS I now realise that my greatest problem with Git is that the conceptual act of “Committing” changes does not do what I typically expect. I think most users of CVCS expect a “commit” to physically take changes from a local workspace and place them into a repository on a separate device somewhere. The moment you realise this is not the case people get worried.

I understand a bit more about DVCS now and this no longer troubles me. Also I’ve found a nice looking GUI front end called SourceTree (for Mac .. not sure about availability on other platforms) Clearly there is more to understand about Git than most other version control systems but I’ve managed to do few simple things with it and I’m going to give it a go. Hopefully I’ll not be back with stories of great woe, because frankly like everyone else has said, I just want to get on with my work.

I’ve used a few different (D)VCS now, and my current pick is bzr. Your “git push ssh:…” would have worked (almost… the syntax is a little different) as expected. bzr (unlike git) knows how to create the repository on the remote, from the client-side. You don’t even need bzr on the server (ex: bzr can push to ftp://), but it helps.

If you think setting up a remote git repo sucks (ironically, git really only works well if you have a centralized repository, e.g. github), try merging. git is pretty braindead when it comes to merges, too. I had to resort to patch files today (!) because git just couldn’t figure things out.