9 ms·

Would you mind explaining why Git is inferior?

by apl 16y ago

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)?
  - shubber 16y ago
    "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." Cheap branching is a fantastic feature - that all the open DVCS tools have. Git focuses on the ability of developers to edit their revision history and provide lovely linear histories (hence the existence of stash, rebase, et al). Git as a tool and as a community encourages one to do so - but the result can be that your local repo and my local repo can no longer be synchronized. Furthermore, it's easy to create a commit of inconsistent code - since you can commit file changes in separate commits. Ultimately git simplifies the work of project maintainers at the expense of day-to-day development, which isn't surprising given it's source, but I think it's a bad trade.

Would you mind explaining why Git is inferior?

by 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)?
- shubber 16y ago
  "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." Cheap branching is a fantastic feature - that all the open DVCS tools have. Git focuses on the ability of developers to edit their revision history and provide lovely linear histories (hence the existence of stash, rebase, et al). Git as a tool and as a community encourages one to do so - but the result can be that your local repo and my local repo can no longer be synchronized. Furthermore, it's easy to create a commit of inconsistent code - since you can commit file changes in separate commits. Ultimately git simplifies the work of project maintainers at the expense of day-to-day development, which isn't surprising given it's source, but I think it's a bad trade.