6 ms·

I'm really tired of Git standing in for "DVCS" - there are so many better options. Bazaar, Mecurial, Monotone, Fossil - check those out. The only win I see in

by shubber 16y ago

I'm really tired of Git standing in for "DVCS" - there are so many better options. Bazaar, Mecurial, Monotone, Fossil - check those out. The only win I see in git is the adoption rate. Which doesn't seem like a real win, just populist shackling.

apl 16y ago
Would you mind explaining why Git is inferior?
- expeditious 16y ago
  A complaint I regularly hear is that it's user interface is frought with peril (and has some poorly-chosen defaults).
  - nuclear_eclipse 16y ago
    "Poorly chosen defaults" is also a synonym for "doesn't work like SVN/HG/BZR".
    - expeditious 16y ago
      I'd suggest that well-chosen defaults means: Make a pretty good guess at the most common usage patterns you expect most of your users to follow, and have your defaults do that by default. I can't comment on whether or not svn/hg/bzr/git/darcs have well-chosen defaults. I only know that I hear it's a common complaint about git.
      - jrockway 16y ago
        I've used git since the early days, and I have trouble using svn and p4 now. Subversion and Perforce should choose better defaults.
      - deleted 16y ago
        [deleted]
    - bugmenot 16y ago
      Might be true. But the only way I'll ever use git is by writing my own svn-like wrapper scripts.
- shubber 16y ago
  A big problem with git is that the commits-and-branching model is poorly thought through. It's very easy to find yourself on no branch at all, for instance, or for a developer to believe they've committed work to a shared branch when in fact it's a private one (and therefore leave the rest of the team hanging.) It's merging workflow is awful - I'm fine with correcting the odd whitespace-as-conflict, but I find the fact that git presents me with >>>>> eyebiting ====== conflict markers <<<<<< even when I'm using a merge tool difficult to excuse. Most of all, more than once, git has completely eaten work, which hasn't happened to me with a VCS since the days of CVS and corrupted repos. Frankly, I see two kinds of arguments in support of git: arguments that derive from the fact that it's a DVCS, and therefore apply to other (IMO better) tools, or "community acceptance" (a la github, Rails) which I find frustrating and circular. Oh, and it's somewhat faster for infrequent operations.
  - nuclear_eclipse 16y ago
    I actually find the way that Git handles branches/commits and the ability to check out an individual ref to be very well thought out and extremely useful. Re "eating work", most of the commands that could potentially "eat work" are explicit about blowing things away, and is more a problem of not knowing what your tool is going to do. And Git will never "eat" anything that's actually been committed or stashed without you explicitly telling Git to drop that data. `git help <command>` should be used liberally if you're not certain of what it's going to do. The documentation is extremely thorough.
  - trustfundbaby 16y ago
    > A big problem with git is that the commits-and-branching model is poorly thought through Really? I think that is one of its strongest points. being able to switch branches by just going 'git checkout <branch>' and immediately having the entire file structure switched out to what's 'contained' in the new branch was a big win for me. Git also alerts you when you've made changes and are switching branches, so you can commit or stash your changes to the branch you were on and not mix it up with the new branch, unless thats what you really want to do. > It's very easy to find yourself on no branch at all Interesting. In what situation would that happen? I always thought you had to be on some sort of branch (master) at least to use git. > It's merging workflow is awful - I'm fine with correcting the odd whitespace-as-conflict, but I find the fact that git presents me with >>>>> eyebiting ====== conflict markers <<<<<< even when I'm using a merge tool difficult to excuse. Sounds like we're complaing about a cosmetic issue. > Frankly, I see two kinds of arguments in support of git: How about the fact that its branching model is pretty awesome and it gives you the tools to do exactly what you want with your version control (rebase, amending commit histories etc)?
eru 16y ago
There are other options. Most of the distributed version control systems are good. What's better seems to be a matter of taste now.
yatsyk 16y ago
The only one drawback of git I know is not so good support of windows OSes. What are the other issues?
- ben_straub 16y ago
  As a Windows git user, this is a minor concern. msysgit works from cmd, powershell, and the include bash prompt, and the gitk and "git gui" tools are actually pretty good once you're familiar with the metaphors. The one thing that still gives me the heebies is the CRLF handling, but I think that's because rails generates unix-style files, and I get a warning from git gui whenever I use those scripts.
  - trustfundbaby 16y ago
    > and the gitk and "git gui" tools are actually pretty good Not to mention tortoise git http://code.google.com/p/tortoisegit/ http://code.google.com/p/tortoisegit/
mhd 16y ago
Github. Yes, a big factor of it is "populist shackling", too. But being popular doesn't just mean that a lot of other people use it, it also means that a lot of other people use it to share code with you. Which is an important step beyond the popularity fallacy.
__david__ 16y ago
You are wrong. I've used most of those and, while on the surface they may appear to be equivalent to git, none of them comes close to having its feature set. Git is popular for a reason--it is complicated, but amazingly powerful. The only non-git DVCS I'd even consider or recommend is darcs--its model is different enough to make it much better for certain workflows than git. It is also incredibly easy to understand and dead simple to use.
- eru 16y ago
  Mercurial is actually more or less equivalent to git. You just need to activate some plugins for, say, rebasing. (I do prefer git, though, for religious reasons.) I've tried using darcs a few years ago (it was my first DVCS system, actually). Did they fix the exponential runtimes one got occasionally? If yes, I'd probably give it another go.
  - __david__ 16y ago
    Yes, darcs 2.0 fixed it or at least drastically minimized it. The problems occurred when there were lots of conflicts between patches. If you try to minimize conflicts (getting often, amending conflicting patches before pushing them) then you'll never run into the problem, even with the old darcs.
  - shubber 16y ago
    It may have improved a lot recently, but the one project I was using Darcs on had this workflow: 1. Pull revisions 2. Discover local workspace was corrupted. 3. Delete local workspace and restart. I'm not a fan of Darcs either. :)
    - __david__ 16y ago
      Corrupted how? (the repo data in the _darcs/ dir, or your local working copy?) I've used darcs extensively for years and have never experienced this.
    - ryanpetrich 16y ago

by shubber 16y ago

apl 16y ago

Would you mind explaining why Git is inferior?

expeditious 16y ago
A complaint I regularly hear is that it's user interface is frought with peril (and has some poorly-chosen defaults).
- nuclear_eclipse 16y ago
  "Poorly chosen defaults" is also a synonym for "doesn't work like SVN/HG/BZR".
  - expeditious 16y ago
    I'd suggest that well-chosen defaults means: Make a pretty good guess at the most common usage patterns you expect most of your users to follow, and have your defaults do that by default. I can't comment on whether or not svn/hg/bzr/git/darcs have well-chosen defaults. I only know that I hear it's a common complaint about git.
    - jrockway 16y ago
      I've used git since the early days, and I have trouble using svn and p4 now. Subversion and Perforce should choose better defaults.
    - deleted 16y ago
      [deleted]
  - bugmenot 16y ago
    Might be true. But the only way I'll ever use git is by writing my own svn-like wrapper scripts.
shubber 16y ago
A big problem with git is that the commits-and-branching model is poorly thought through. It's very easy to find yourself on no branch at all, for instance, or for a developer to believe they've committed work to a shared branch when in fact it's a private one (and therefore leave the rest of the team hanging.) It's merging workflow is awful - I'm fine with correcting the odd whitespace-as-conflict, but I find the fact that git presents me with >>>>> eyebiting ====== conflict markers <<<<<< even when I'm using a merge tool difficult to excuse. Most of all, more than once, git has completely eaten work, which hasn't happened to me with a VCS since the days of CVS and corrupted repos. Frankly, I see two kinds of arguments in support of git: arguments that derive from the fact that it's a DVCS, and therefore apply to other (IMO better) tools, or "community acceptance" (a la github, Rails) which I find frustrating and circular. Oh, and it's somewhat faster for infrequent operations.
- nuclear_eclipse 16y ago
  I actually find the way that Git handles branches/commits and the ability to check out an individual ref to be very well thought out and extremely useful. Re "eating work", most of the commands that could potentially "eat work" are explicit about blowing things away, and is more a problem of not knowing what your tool is going to do. And Git will never "eat" anything that's actually been committed or stashed without you explicitly telling Git to drop that data. `git help <command>` should be used liberally if you're not certain of what it's going to do. The documentation is extremely thorough.
- trustfundbaby 16y ago
  > A big problem with git is that the commits-and-branching model is poorly thought through Really? I think that is one of its strongest points. being able to switch branches by just going 'git checkout <branch>' and immediately having the entire file structure switched out to what's 'contained' in the new branch was a big win for me. Git also alerts you when you've made changes and are switching branches, so you can commit or stash your changes to the branch you were on and not mix it up with the new branch, unless thats what you really want to do. > It's very easy to find yourself on no branch at all Interesting. In what situation would that happen? I always thought you had to be on some sort of branch (master) at least to use git. > It's merging workflow is awful - I'm fine with correcting the odd whitespace-as-conflict, but I find the fact that git presents me with >>>>> eyebiting ====== conflict markers <<<<<< even when I'm using a merge tool difficult to excuse. Sounds like we're complaing about a cosmetic issue. > Frankly, I see two kinds of arguments in support of git: How about the fact that its branching model is pretty awesome and it gives you the tools to do exactly what you want with your version control (rebase, amending commit histories etc)?

eru 16y ago

There are other options. Most of the distributed version control systems are good. What's better seems to be a matter of taste now.

yatsyk 16y ago

The only one drawback of git I know is not so good support of windows OSes. What are the other issues?

ben_straub 16y ago
As a Windows git user, this is a minor concern. msysgit works from cmd, powershell, and the include bash prompt, and the gitk and "git gui" tools are actually pretty good once you're familiar with the metaphors. The one thing that still gives me the heebies is the CRLF handling, but I think that's because rails generates unix-style files, and I get a warning from git gui whenever I use those scripts.
- trustfundbaby 16y ago
  > and the gitk and "git gui" tools are actually pretty good Not to mention tortoise git http://code.google.com/p/tortoisegit/ http://code.google.com/p/tortoisegit/

mhd 16y ago

Github. Yes, a big factor of it is "populist shackling", too. But being popular doesn't just mean that a lot of other people use it, it also means that a lot of other people use it to share code with you. Which is an important step beyond the popularity fallacy.

__david__ 16y ago

You are wrong. I've used most of those and, while on the surface they may appear to be equivalent to git, none of them comes close to having its feature set. Git is popular for a reason--it is complicated, but amazingly powerful. The only non-git DVCS I'd even consider or recommend is darcs--its model is different enough to make it much better for certain workflows than git. It is also incredibly easy to understand and dead simple to use.

eru 16y ago
Mercurial is actually more or less equivalent to git. You just need to activate some plugins for, say, rebasing. (I do prefer git, though, for religious reasons.) I've tried using darcs a few years ago (it was my first DVCS system, actually). Did they fix the exponential runtimes one got occasionally? If yes, I'd probably give it another go.
- __david__ 16y ago
  Yes, darcs 2.0 fixed it or at least drastically minimized it. The problems occurred when there were lots of conflicts between patches. If you try to minimize conflicts (getting often, amending conflicting patches before pushing them) then you'll never run into the problem, even with the old darcs.
- shubber 16y ago
  It may have improved a lot recently, but the one project I was using Darcs on had this workflow: 1. Pull revisions 2. Discover local workspace was corrupted. 3. Delete local workspace and restart. I'm not a fan of Darcs either. :)
  - __david__ 16y ago
    Corrupted how? (the repo data in the _darcs/ dir, or your local working copy?) I've used darcs extensively for years and have never experienced this.
  - ryanpetrich 16y ago