3 ms·

Disclaimer: I am a primary maintainer for a couple open source projects and I contribute to a few others for 10+ years now. And I've seen quite a few email thre

by lsh123 12y ago

Disclaimer: I am a primary maintainer for a couple open source projects and I contribute to a few others for 10+ years now. And I've seen quite a few email threads similar to this one :) 1) If you don't like how postfix is run then feel free to use other tools, fork it, or start your own project. This is open source and you have the power to do it better. If you are indeed right then your project will be successful. Put the money (effort) where you mouth is. 2) You can politely suggest something but you will get a much better traction if you first establish your reputation among people who work on this project by contributing code, documentation, whatever or even simply answering the questions in the mailing list (after about a year it gets really boring since questions are always the same). 3) (IMHO) There is no silver bullet. Git (or any other tool) will not make your code/project better. Moreover you might find that Git (or any other tool) is not perfect and there are problems with it in a particular environment (hint: there is no free lunch). Recognizing the tradeoffs is a very important skill for a software developer. Learn it early and you'll make less mistakes.

mixologic 12y ago
Having worked with CVS, Perforce, subversion, bzr, mercurial, and git, in distributed teams, as a sole developer and in large local teams for over 20 years, I can't think of a single plausible situation in which git is not superior in every way to all the other version control systems. Git is a tool, and it's certainly not going to be a 'flip a switch and everything is better'. It does require that you define how you're going to use it in your particular context, but the only tradeoff I can see with git is learning it. It's interface and naming is an absolute horror show of usability, but its no worse that something like regular expressions or vim/emacs. But once it's in place, you have change management calculus, and everything else was algebra at best. I understand the frustration of people who are used to having the benefits of open history in addition to open source. And who don't want to step back 10 years and learn dead end technologies, and who aren't used to being confronted with ivory towerism or gatekeeperism. Otoh, I also understand why a maintainer would want to keep their codebases close to their chest, when they've achieved expert level finesse in a project/codebase, and the noob hordes with their ill-conceived ideas demand responses to their pull requests because they spent their free time writing some crap, and demand you spend your free time educating them on why their patch is a tub full of fail.
- lsh123 12y ago
  I've replied to another comment - there are scenarios when Git is not the best choice (imho) :) Said that I am using Git for pretty much everything right now simply because it is "good enough" and I am lazy to switch between tools.
- papaf 12y ago
  I can't think of a single plausible situation in which git is not superior in every way to all the other version control systems. I don't want to get into an emacs/vi style flamewar but other VCSs have their own advantages, and are better in some situations: - I prefer SVNs handling of trees/subtrees. I can checkout and work on one small part of a large project. - Fossil has ticketing and wiki out of the box. It is easier to set up a server and enables true distributed offline working. - Mercurial is easier to use for the most frequent use cases.
  - mixologic 12y ago
    Git's submodules and git-subtree are definitely clumsy to work with, but you can always use sparse checkout if you want to work on a small part of a large project. Ticket handling/wiki aren't really version control features. Decoupling those features from your VCS allows you to select the one that works best for your situation. Mercurial is easier to learn for the most frequent use cases, and its interface make a lot more sense. No argument there. But like I said earlier, once you do learn it, its no more difficult to use, follows the same paradigms, but really allows for the edge cases to shine.
girvo 12y ago
Note that I'm not disagreeing with you, but I can't see where using a DVCS like Git could be a negative?
- lsh123 12y ago
  IMHO, for a single commiter use-case DVCS add an un-necessary level of complexity. I use Git for my personal projects simply because I am lazy to switch between different tools. And even for multiple contributors, Git is not ideal. For example, the "single" source tree version doesn't allow parallel check-ins in different parts of the code. I've seen a 50+ developers project with an active trunk where Git was a blocker because it was hard to push your code because of other people pushes. For example, SVN is much better in this regard and allows commits as long as it is not in the same files. Yes, one can split the big project into sub-projects, etc. but sometimes it is not really possible.
  - mixologic 12y ago
    "I've seen a 50+ developers project with an active trunk where Git was a blocker because it was hard to push your code because of other people pushes" That's a clear misunderstanding of how to use git. The whole idea of having a single source tree is unnecessarily limiting - everybody works in their own branches, pushes to a origin/github remote, and when their work is gtg for the trunk, they, in their branch do a git pull --rebase, or alternately do a `git fetch; git rebase origin/master`. If they haven't touched any files that other people have touched, it just moves their branch point off of the current tip of origin/master, and they can merge their changes into master and push. The only time it should be hard to push code is if both people made changes to the same file, and realistically, the same lines of a file. Then you get a merge conflict which is awesome, because it's made you aware that what you're working on and what somebody else is working on may be overlapping.

by lsh123 12y ago

mixologic 12y ago

Having worked with CVS, Perforce, subversion, bzr, mercurial, and git, in distributed teams, as a sole developer and in large local teams for over 20 years, I can't think of a single plausible situation in which git is not superior in every way to all the other version control systems. Git is a tool, and it's certainly not going to be a 'flip a switch and everything is better'. It does require that you define how you're going to use it in your particular context, but the only tradeoff I can see with git is learning it. It's interface and naming is an absolute horror show of usability, but its no worse that something like regular expressions or vim/emacs. But once it's in place, you have change management calculus, and everything else was algebra at best. I understand the frustration of people who are used to having the benefits of open history in addition to open source. And who don't want to step back 10 years and learn dead end technologies, and who aren't used to being confronted with ivory towerism or gatekeeperism. Otoh, I also understand why a maintainer would want to keep their codebases close to their chest, when they've achieved expert level finesse in a project/codebase, and the noob hordes with their ill-conceived ideas demand responses to their pull requests because they spent their free time writing some crap, and demand you spend your free time educating them on why their patch is a tub full of fail.

lsh123 12y ago
I've replied to another comment - there are scenarios when Git is not the best choice (imho) :) Said that I am using Git for pretty much everything right now simply because it is "good enough" and I am lazy to switch between tools.
papaf 12y ago
I can't think of a single plausible situation in which git is not superior in every way to all the other version control systems. I don't want to get into an emacs/vi style flamewar but other VCSs have their own advantages, and are better in some situations: - I prefer SVNs handling of trees/subtrees. I can checkout and work on one small part of a large project. - Fossil has ticketing and wiki out of the box. It is easier to set up a server and enables true distributed offline working. - Mercurial is easier to use for the most frequent use cases.
- mixologic 12y ago
  Git's submodules and git-subtree are definitely clumsy to work with, but you can always use sparse checkout if you want to work on a small part of a large project. Ticket handling/wiki aren't really version control features. Decoupling those features from your VCS allows you to select the one that works best for your situation. Mercurial is easier to learn for the most frequent use cases, and its interface make a lot more sense. No argument there. But like I said earlier, once you do learn it, its no more difficult to use, follows the same paradigms, but really allows for the edge cases to shine.

girvo 12y ago

Note that I'm not disagreeing with you, but I can't see where using a DVCS like Git could be a negative?

lsh123 12y ago
IMHO, for a single commiter use-case DVCS add an un-necessary level of complexity. I use Git for my personal projects simply because I am lazy to switch between different tools. And even for multiple contributors, Git is not ideal. For example, the "single" source tree version doesn't allow parallel check-ins in different parts of the code. I've seen a 50+ developers project with an active trunk where Git was a blocker because it was hard to push your code because of other people pushes. For example, SVN is much better in this regard and allows commits as long as it is not in the same files. Yes, one can split the big project into sub-projects, etc. but sometimes it is not really possible.
- mixologic 12y ago
  "I've seen a 50+ developers project with an active trunk where Git was a blocker because it was hard to push your code because of other people pushes" That's a clear misunderstanding of how to use git. The whole idea of having a single source tree is unnecessarily limiting - everybody works in their own branches, pushes to a origin/github remote, and when their work is gtg for the trunk, they, in their branch do a git pull --rebase, or alternately do a `git fetch; git rebase origin/master`. If they haven't touched any files that other people have touched, it just moves their branch point off of the current tip of origin/master, and they can merge their changes into master and push. The only time it should be hard to push code is if both people made changes to the same file, and realistically, the same lines of a file. Then you get a merge conflict which is awesome, because it's made you aware that what you're working on and what somebody else is working on may be overlapping.