3 ms·

But if you have hundreds of developers, and you have a dynamic trust network (I trust some people, they trust others, and we all tend to trust people more or le

But if you have hundreds of developers, and you have a dynamic trust network (I trust some people, they trust others, and we all tend to trust people more or less depending on what they work on), the CVS model is absolutely HORRID. It just doesn't work. I can count on one hand the number of projects described by that sentence. No surprise, the Linux kernel is one of them. Linus built a tool to satisfy his needs. But most developers work in smaller groups, and these groups have explicit trust. Working at a company, the trust network isn't dynamic. Even in large open source projects, most of the commits are by a handful of individuals. It's not a big deal if the occasional one-time contributor e-mails a patch. But most of my gripes with git don't have to do with its ideas. Although it's distributed revision control, in my experience everyone designates one repo as authoritative. Like centralized RVCs, certain users are explicitly granted write access to said authoritative repo. So git ends up working like an svn repo with a ton of branches. My complaints about git have to do with its interface. Coming from svn, git is very frustrating to use. Certain benign commands in svn will erase your data in git-land. For example, "git checkout filename" is the equivalent of "svn revert filename"; it erases any uncommitted changes. Of course, git has a revert command as well, but it doesn't behave like other RVCs. Git checkout can bite you if you have a branch with the same name as a file or directory in your source tree. My biggest annoyance is if I accidentally commit and push something. Usually it's when I forget which branch I've checked out. Undoing a commit/push means rebasing or resetting, and that's where git drives me insane. I have used subversion, CVS, and even Visual SourceSafe, but only in git have I lost previous commits. Again with the misleading terminology. Why call them commits if you can destroy them with a single command?

parbo 17y ago
It sounds like you'd like Mercurial better. The interface is much more SVN-like.
- AngryParsley 17y ago
  I totally forgot about Mercurial, probably because I have no bad experiences associated with it. I haven't used it much, but the times I have used it have been forgetful. I think that's a good thing when it comes to revision control.
- ido 17y ago
  I tried git only to be frustrated by its interface and come back to svn. A few months after that I tried hg and never looked back.
Deestan 17y ago
> Undoing a commit/push means rebasing or resetting, and that's where git drives me insane. To look on the bright side first, Git is the only(+) DVCS in which you can clean up these kinds of mistakes without cluttering the revision history with "revert" and "oops sorry" changesets. :) > I have used subversion, CVS, and even Visual SourceSafe, but only in git have I lost previous commits. Again with the misleading terminology. Why call them commits if you can destroy them with a single command? The changesets are not really destroyed; you have just redeclared the official revision history not to include them, so they aren't visible. The changesets are still alive within the database until the garbage collector picks them up at a later date (then they will be destroyed), and you can access them via looking up the revision ID in the revision log (or sometimes just by scrolling up the terminal window). Once you have the revision ID, you can tag it (or declare it a new branch) so you don't lose it until you're done with the cleanup. Then you can cherry-pick, rebase, merge or do whatever you want to fix the erroneous commit. This bit of Git causes a lot of headache among new Git users for the first few weeks (me included), since you need to understand the underlying database and really toy around with it a lot to understand how to do stuff like this properly. Though once I finally got it, Git replaced HG as my favourite VCS. (+) That I know of at least. :) HG supports a "rollback" command, but that only covers one changeset, and you can't really use it if you have pushed your changeset or if it has been pulled by somebody else.

parbo 17y ago

It sounds like you'd like Mercurial better. The interface is much more SVN-like.

AngryParsley 17y ago
I totally forgot about Mercurial, probably because I have no bad experiences associated with it. I haven't used it much, but the times I have used it have been forgetful. I think that's a good thing when it comes to revision control.
ido 17y ago
I tried git only to be frustrated by its interface and come back to svn. A few months after that I tried hg and never looked back.

Deestan 17y ago

> Undoing a commit/push means rebasing or resetting, and that's where git drives me insane. To look on the bright side first, Git is the only(+) DVCS in which you can clean up these kinds of mistakes without cluttering the revision history with "revert" and "oops sorry" changesets. :) > I have used subversion, CVS, and even Visual SourceSafe, but only in git have I lost previous commits. Again with the misleading terminology. Why call them commits if you can destroy them with a single command? The changesets are not really destroyed; you have just redeclared the official revision history not to include them, so they aren't visible. The changesets are still alive within the database until the garbage collector picks them up at a later date (then they will be destroyed), and you can access them via looking up the revision ID in the revision log (or sometimes just by scrolling up the terminal window). Once you have the revision ID, you can tag it (or declare it a new branch) so you don't lose it until you're done with the cleanup. Then you can cherry-pick, rebase, merge or do whatever you want to fix the erroneous commit. This bit of Git causes a lot of headache among new Git users for the first few weeks (me included), since you need to understand the underlying database and really toy around with it a lot to understand how to do stuff like this properly. Though once I finally got it, Git replaced HG as my favourite VCS. (+) That I know of at least. :) HG supports a "rollback" command, but that only covers one changeset, and you can't really use it if you have pushed your changeset or if it has been pulled by somebody else.