5 ms·

Sounds similar to my experiences with Bazaar many years ago. Ended up converting all project over to Git once we realised that nearly all external developers w

Sounds similar to my experiences with Bazaar many years ago. Ended up converting all project over to Git once we realised that nearly all external developers we worked with preferred Git and didn't have a clue about Bzr. Semi interesting full circle side note: One of those projects was actually a rudimentary version control system for a report writing app, which used SQLite as the VC data store.

ropeadopepope 9y ago
> Ended up converting all project over to Git once we realised that nearly all external developers we worked with preferred Git and didn't have a clue about Bzr. Why? There was a time not too long ago where this was true about git. Companies switched to git anyway.
- danielvf 9y ago
  Git was so astonishingly better than SVN that most developers were instantly hooked. But when you know git and try bzr, it’s mostly the same thing but with different commands. Any gain is small and the pain is instant.
raimue 9y ago
I switched as well from bzr to git. The most important thing that Git offered over alternatives was amending commits to fix mistakes, reordering commits on the local branch with 'git rebase -i', and partial checkins with the staging area. Git was the first VCS I used which could commit unrelated changes separately with ease. With other tools, you manually have to copy changes around until the working copy only contains what you want to commit. Despite that, the Git command line interface is horribly inconsistent. Commands take separate words, `--options` or one-character flags without a scheme. Lots of synonyms such as staging area, index, or cache all meaning the same thing in the terminology does not help to make learning Git easier. For new users I would recommend Gitless, which tries to create a better interface to git and to solve the ambiguity in commands. As Gitless is a frontend to libgit2, it works with any git repository and you can also use normal git commands. The downside is that documentation usually only shows how to do stuff with 'git'. If you only learned 'gl', you have no idea how to reproduce it. http://gitless.com/ http://gitless.com/

ropeadopepope 9y ago

> Ended up converting all project over to Git once we realised that nearly all external developers we worked with preferred Git and didn't have a clue about Bzr. Why? There was a time not too long ago where this was true about git. Companies switched to git anyway.

danielvf 9y ago
Git was so astonishingly better than SVN that most developers were instantly hooked. But when you know git and try bzr, it’s mostly the same thing but with different commands. Any gain is small and the pain is instant.

raimue 9y ago

I switched as well from bzr to git. The most important thing that Git offered over alternatives was amending commits to fix mistakes, reordering commits on the local branch with 'git rebase -i', and partial checkins with the staging area. Git was the first VCS I used which could commit unrelated changes separately with ease. With other tools, you manually have to copy changes around until the working copy only contains what you want to commit. Despite that, the Git command line interface is horribly inconsistent. Commands take separate words, `--options` or one-character flags without a scheme. Lots of synonyms such as staging area, index, or cache all meaning the same thing in the terminology does not help to make learning Git easier. For new users I would recommend Gitless, which tries to create a better interface to git and to solve the ambiguity in commands. As Gitless is a frontend to libgit2, it works with any git repository and you can also use normal git commands. The downside is that documentation usually only shows how to do stuff with 'git'. If you only learned 'gl', you have no idea how to reproduce it. http://gitless.com/ http://gitless.com/