7 ms·

When people say they don't like git, I lose a little faith in them as a programmer and/or engineer. This is probably due to my own biases of having worked with

by rplst8 10y ago

When people say they don't like git, I lose a little faith in them as a programmer and/or engineer. This is probably due to my own biases of having worked with folks that just don't want to invest the time in learning it. That or they are afraid of branching/merging. To me this indicates intellectual laziness which isn't the kind of laziness that makes a good programmer (as is with the quote from Larry Wall and the kind of laziness he speaks of).

cmrdporcupine 10y ago
Or we've used other DVCS systems like Mercurial or Bazaar or Bitkeeper that had sane CLIs with consistent and self-explanatory user interfaces. Git is powerful. And also seems to have a powerfully elitist community around it, as evidenced from your comment.
Certhas 10y ago
I work with a whole bunch of scientists that program. Some mathematicians, some theoretical physicists. We run into git issues more often than we should. It's lazy to blame git issues on intellectual laziness. Any human designed system can be learned with enough effort but in git there seems to be significant superfluous effort. Effort that probably makes sense for some use-cases that git was developed for, but as it has become ubiquitous and now we all have to live with it, programmers or not. In my view, git has too much state. The state of my directory, the state of my branch, the staging area, the stash, etc.. these all interact in non-trivial ways when merging/branching. Gitless shows that it can be done with less state. And the design of the interface _is_ atrocious: http://stevelosh.com/blog/2013/04/git-koans/ http://stevelosh.com/blog/2013/04/git-koans/
- zajd 10y ago
  It's really not though. And posting articles that pretend like "git rev-parse --abbrev-ref HEAD" is the best way to view what branch you're working on just makes you look dumber than you do for acting like git is difficult to work with. If people writing blog posts about "how bad the git interface is" and more time instructing newer programmers (the only ones who have any reason to complain about git) on how to correctly use the tools maybe we wouldn't have to hear so much whining about the tool. Anyone who has been in the field understands that for all it's tradeoffs git is an incredible breath of fresh air from systems like CVS/SVN.
  - dhimes 10y ago
    Is there a gentle introduction, comparable to hginit.com for mercurial? When I first started version control I was trying to choose between hg and git. The site hginit was huge for getting me to swing towards hg.
    - zajd 10y ago
      https://www.atlassian.com/git/tutorials/ https://www.atlassian.com/git/tutorials/ This is generally where I point people who have a technical background
      - dhimes 10y ago
        Thank you.
      - rplst8 10y ago
        Atlassian has put some great "mind abstractions" on top of git to help people understand how to use it. It's definitely fashionable these days to hate on complicated tools. I wonder if the same is true in other professions. Simple tools are easy to use, yes. But anyone who as worked on a Bicycle or other equipment that requires specialized tools knows that the having the correct, often more complicated tool beats the hell out of wacking on it with the wrong type of wrench.
        dhimes 10y ago
        Right tool definitely wins. Mecurial is excellent, though; it solves all of my problems. But I feel like I should at least know some git basics. And I want to start at the simple beginning just in case I have some misunderstandings about what I'm doing in hg.
        rkangel 10y ago
        Software allows a better abstraction of a problem than anything in the mechanical world. Progression in software craftsmanship has shown us that powerful functionality can be hidden behind a simple interface, if sufficient thought and design is put into it. Our expectations of how we interact with software have risen over the years, and that's a good thing.
kasey_junk 10y ago
When people suggest that git is great I lose a little faith in them as a programmer cause it indicates to me they don't have much breadth if experience with source control systems & they are too intellectually lazy to investigate alternatives. Could just be my biases I guess.
- favadi 10y ago
  I still think that git is great, only git - the cli is bad.
- musicnarcoman 10y ago
  So, what alternatives are you suggesting? I have tried and used Mercurial, SVN, RCS, CVS, Bitkeeper, TFS, Bazaar, Perforce, Darcs and of course Git. Granted, Git may not be great, but it is still my first choice.
  - kasey_junk 10y ago
    Hg is a very similar model to git but doesn't have the cli problems it does. Darcs is distributed with a different (and interesting) model that doesn't have the cli problems get does. But honestly for lots of teams dvcs is not that big an advantage (how many teams are syncing around github right now) which means something like Accurev might be a better choice. It uses a concept of streams which is pretty interesting and is GUI oriented which some people like.
    - Grue3 10y ago
      Hg has a lot of problems. It has bookmarks AND branches (for some reason). To edit your commit history you need to pray to the elder gods and sacrifice a newborn. I consider myself pretty smart and yet my mind went completely blank every time I read about anything related to Mercurial Queues. The default install lacks too many features, you need to enable extensions to do even the most basic stuff, like stashing. Darcs is obviously better than git, but very few people know it exists. And none of free web repositories support it.
bluejekyll 10y ago
I use git all the time and prefer it for all types of workflow as a VCS, but this idea that git is perfect and it's your own fault for not learning it properly is ridiculous. UX/UI in programs is important. I believe that git has one of the worst, most inconsistent UX's of all time. You can see this by the fractured commands. Quick examples: 'git reset' vs. 'git revert' and sometime 'git checkout' 'git checkout' vs. 'git clone' vs. 'git pull' vs. 'git fetch' vs. 'git cherrypick' 'git rebase' vs. 'git merge' vs. 'git merge --squash' Each one of these performs actions on a repo giving you immense power and control to do specific actions, but it's horrible UX. It's very easy to end up in a detached HEAD state, or have accidentally rebased a repo so it's out of alignment with a remote, leaving you with the trouble of dealing with that. It's crap experience, and all I want to do is code. What does it say when resolving these problems the easiest thing is to just reclone the remote repo? I commend this project for trying to apply some sanity to the entire thing.
- zajd 10y ago
  > What does it say when resolving these problems the easiest thing is to just reclone the remote repo? It says the git works really well because the CLI offers a simple way to "undo" any mistakes you've made. The real reason people struggle with git, and I've seen this in many other programs/places is that they rely on discoverability and just randomly try commands until they work. Git's simplicity is it's downfall. You don't see people wrapping Angular2 in other frameworks to deal with the warts. There's a reason people are told to look at man pages all the time, the command line is not the place to play "discoverability". There's already plenty of suggestions and help features built into the tool. > It's crap experience, and all I want to do is code. - every engineer when first experiencing version control
  - bluejekyll 10y ago
    > It says the git works really well because the CLI offers a simple way to "undo" any mistakes you've made. This let's the design off the hook to easily. Yes, on the one hand this is a great feature, but on the other, you are deleting and restarting your workspace. It's not a great UX, it's just a simple workaround for a bad one. > - every engineer when first experiencing version control no, wrong. git is unique in the amount of information that you need to know just to get started with it.
amag 10y ago
I'm a programmer because I love to see things I imagine come to life, not because I love to learn arcane CLI interfaces. I can appreciate the beauty of the underlying design and structure of git, but the git CLI is just a horrible turd IMHO. Am I lazy? Sure, my mental ability is not infinite (ASFAIK) and I rather focus it on solving my actual problem rather than trying to find the right git-incantation for making git shut up and leave me the f* alone... I have a decent understanding of the underlying structure of git and I often know what needs to be done in terms of how one commit relates to another but git CLI...
zwieback 10y ago
I like git a lot and wish everyone standardized on it. I use the CLI almost exclusively but from my perspective it's terrible: cryptic and very inconsistent. Looking back at my RCS history (RCS->VSS->MKSSI->CVS->SVN->git) I have to say that all of them were either hard to use or plain bad (VSS). The problem RCSs are trying to solve is hard, that's why the tools are simultaneously indispensible and frustrating.
fail2fail2ban 10y ago
Git works really well but I've had some exposure to Canonical's Bazaar (bzr) in the past and at a high level; I'd say it's easier to not shoot yourself in the foot with bzr while still accomplishing pretty much what Git does. I'm not knocking Git at all, just bringing some background on an alternative tool I'd say is in the same class.
twic 10y ago
Whereas when people say they do like Git, I lose a little faith in them as a programmer and/or engineer. Because the only ways you could like Git are either to be so lazy and incurious as to be unfamiliar with the alternatives (Mercurial, and everything else that's come along since), or to have such bad judgment that you prefer Git to them.
na85 10y ago
I don't like git because I have zero confidence that it won't do something dumb like fail to diff properly requiring me to merge 980 diffs in a single file while it puts the <<<<<<<< and >>>>>>>> markers in the wrong places, randomly transposing lines from one part of a file to another for no discernible reason. You know, like happened to me today.
- deleted 10y ago
  [deleted]
CJefferson 10y ago
Some reasons I don't like git, straight off the top of my head. * Some commands require remote branch, others require remote/branch. I can never remember which. * git lets you create branches with names like 'remote/branch', at which point it starts going crazy because when I then write remote/branch, it doesn't know if I mean branch on remote, or the local branch remote/branch. * When merging / rebasing goes wrong, it can be hard (or impossible) to recover back to the state I started from.
jcranmer 10y ago
My first experience with a VCS was using Mercurial, about a decade ago. In that time, I've only had at most three or four instances where I so borked the repository that I had to destroy it and start again. This includes the time when I didn't know anything about VCS and was liable to foot-gun myself. I probably first used Git about 5, 6 years ago, and, despite using it at a much reduced frequency (virtually all my git usage is via hg-git nowadays), I've easily had a dozen times where it was easier to blow away a repository than fix it. Obviously, heavy prior experience with Mercurial does color one's views about UX, but the experience with Git that I have had--and that I have seen many others concur with--is that the UX makes it way too easy to get you in states that you don't know what to do. But that's not the biggest flaw with Git. The biggest flaw is the community: when you don't know what to do, and you start trying to find the answer, instead of being told "this is how you fix it," you instead get a lecture on the full internals of Git, and why the crazy incantation should be really obvious to any user. Is it any surprise that one would find it easier to blow away the directory and recreate the five-line build system fix whose merge conflict caused the mess in the first place? Your comment is a picture-perfect of this community hostility that I see with Git that I don't see with other VCS. There definitely seems to be a sentiment that there is One True Way™ to do things, and if you're not doing it like that, you are wrong. I care to disagree: a VCS is a tool--it should support my workflow, not dictate it. I find that the community around Mercurial is much more in agreement with the philosophy I hold, and unsurprisingly, I've generally found Mercurial to be superior than Git.

by rplst8 10y ago

cmrdporcupine 10y ago

Or we've used other DVCS systems like Mercurial or Bazaar or Bitkeeper that had sane CLIs with consistent and self-explanatory user interfaces. Git is powerful. And also seems to have a powerfully elitist community around it, as evidenced from your comment.

Certhas 10y ago

I work with a whole bunch of scientists that program. Some mathematicians, some theoretical physicists. We run into git issues more often than we should. It's lazy to blame git issues on intellectual laziness. Any human designed system can be learned with enough effort but in git there seems to be significant superfluous effort. Effort that probably makes sense for some use-cases that git was developed for, but as it has become ubiquitous and now we all have to live with it, programmers or not. In my view, git has too much state. The state of my directory, the state of my branch, the staging area, the stash, etc.. these all interact in non-trivial ways when merging/branching. Gitless shows that it can be done with less state. And the design of the interface _is_ atrocious: http://stevelosh.com/blog/2013/04/git-koans/ http://stevelosh.com/blog/2013/04/git-koans/

zajd 10y ago
It's really not though. And posting articles that pretend like "git rev-parse --abbrev-ref HEAD" is the best way to view what branch you're working on just makes you look dumber than you do for acting like git is difficult to work with. If people writing blog posts about "how bad the git interface is" and more time instructing newer programmers (the only ones who have any reason to complain about git) on how to correctly use the tools maybe we wouldn't have to hear so much whining about the tool. Anyone who has been in the field understands that for all it's tradeoffs git is an incredible breath of fresh air from systems like CVS/SVN.
- dhimes 10y ago
  Is there a gentle introduction, comparable to hginit.com for mercurial? When I first started version control I was trying to choose between hg and git. The site hginit was huge for getting me to swing towards hg.
  - zajd 10y ago
    https://www.atlassian.com/git/tutorials/ https://www.atlassian.com/git/tutorials/ This is generally where I point people who have a technical background
    - dhimes 10y ago
      Thank you.
    - rplst8 10y ago
      Atlassian has put some great "mind abstractions" on top of git to help people understand how to use it. It's definitely fashionable these days to hate on complicated tools. I wonder if the same is true in other professions. Simple tools are easy to use, yes. But anyone who as worked on a Bicycle or other equipment that requires specialized tools knows that the having the correct, often more complicated tool beats the hell out of wacking on it with the wrong type of wrench.
      - dhimes 10y ago
        Right tool definitely wins. Mecurial is excellent, though; it solves all of my problems. But I feel like I should at least know some git basics. And I want to start at the simple beginning just in case I have some misunderstandings about what I'm doing in hg.
      - rkangel 10y ago
        Software allows a better abstraction of a problem than anything in the mechanical world. Progression in software craftsmanship has shown us that powerful functionality can be hidden behind a simple interface, if sufficient thought and design is put into it. Our expectations of how we interact with software have risen over the years, and that's a good thing.

kasey_junk 10y ago

When people suggest that git is great I lose a little faith in them as a programmer cause it indicates to me they don't have much breadth if experience with source control systems & they are too intellectually lazy to investigate alternatives. Could just be my biases I guess.

favadi 10y ago
I still think that git is great, only git - the cli is bad.
musicnarcoman 10y ago
So, what alternatives are you suggesting? I have tried and used Mercurial, SVN, RCS, CVS, Bitkeeper, TFS, Bazaar, Perforce, Darcs and of course Git. Granted, Git may not be great, but it is still my first choice.
- kasey_junk 10y ago
  Hg is a very similar model to git but doesn't have the cli problems it does. Darcs is distributed with a different (and interesting) model that doesn't have the cli problems get does. But honestly for lots of teams dvcs is not that big an advantage (how many teams are syncing around github right now) which means something like Accurev might be a better choice. It uses a concept of streams which is pretty interesting and is GUI oriented which some people like.
  - Grue3 10y ago
    Hg has a lot of problems. It has bookmarks AND branches (for some reason). To edit your commit history you need to pray to the elder gods and sacrifice a newborn. I consider myself pretty smart and yet my mind went completely blank every time I read about anything related to Mercurial Queues. The default install lacks too many features, you need to enable extensions to do even the most basic stuff, like stashing. Darcs is obviously better than git, but very few people know it exists. And none of free web repositories support it.

bluejekyll 10y ago

I use git all the time and prefer it for all types of workflow as a VCS, but this idea that git is perfect and it's your own fault for not learning it properly is ridiculous. UX/UI in programs is important. I believe that git has one of the worst, most inconsistent UX's of all time. You can see this by the fractured commands. Quick examples: 'git reset' vs. 'git revert' and sometime 'git checkout' 'git checkout' vs. 'git clone' vs. 'git pull' vs. 'git fetch' vs. 'git cherrypick' 'git rebase' vs. 'git merge' vs. 'git merge --squash' Each one of these performs actions on a repo giving you immense power and control to do specific actions, but it's horrible UX. It's very easy to end up in a detached HEAD state, or have accidentally rebased a repo so it's out of alignment with a remote, leaving you with the trouble of dealing with that. It's crap experience, and all I want to do is code. What does it say when resolving these problems the easiest thing is to just reclone the remote repo? I commend this project for trying to apply some sanity to the entire thing.

zajd 10y ago
> What does it say when resolving these problems the easiest thing is to just reclone the remote repo? It says the git works really well because the CLI offers a simple way to "undo" any mistakes you've made. The real reason people struggle with git, and I've seen this in many other programs/places is that they rely on discoverability and just randomly try commands until they work. Git's simplicity is it's downfall. You don't see people wrapping Angular2 in other frameworks to deal with the warts. There's a reason people are told to look at man pages all the time, the command line is not the place to play "discoverability". There's already plenty of suggestions and help features built into the tool. > It's crap experience, and all I want to do is code. - every engineer when first experiencing version control
- bluejekyll 10y ago
  > It says the git works really well because the CLI offers a simple way to "undo" any mistakes you've made. This let's the design off the hook to easily. Yes, on the one hand this is a great feature, but on the other, you are deleting and restarting your workspace. It's not a great UX, it's just a simple workaround for a bad one. > - every engineer when first experiencing version control no, wrong. git is unique in the amount of information that you need to know just to get started with it.

amag 10y ago

I'm a programmer because I love to see things I imagine come to life, not because I love to learn arcane CLI interfaces. I can appreciate the beauty of the underlying design and structure of git, but the git CLI is just a horrible turd IMHO. Am I lazy? Sure, my mental ability is not infinite (ASFAIK) and I rather focus it on solving my actual problem rather than trying to find the right git-incantation for making git shut up and leave me the f* alone... I have a decent understanding of the underlying structure of git and I often know what needs to be done in terms of how one commit relates to another but git CLI...

zwieback 10y ago

I like git a lot and wish everyone standardized on it. I use the CLI almost exclusively but from my perspective it's terrible: cryptic and very inconsistent. Looking back at my RCS history (RCS->VSS->MKSSI->CVS->SVN->git) I have to say that all of them were either hard to use or plain bad (VSS). The problem RCSs are trying to solve is hard, that's why the tools are simultaneously indispensible and frustrating.

fail2fail2ban 10y ago

Git works really well but I've had some exposure to Canonical's Bazaar (bzr) in the past and at a high level; I'd say it's easier to not shoot yourself in the foot with bzr while still accomplishing pretty much what Git does. I'm not knocking Git at all, just bringing some background on an alternative tool I'd say is in the same class.

twic 10y ago

Whereas when people say they do like Git, I lose a little faith in them as a programmer and/or engineer. Because the only ways you could like Git are either to be so lazy and incurious as to be unfamiliar with the alternatives (Mercurial, and everything else that's come along since), or to have such bad judgment that you prefer Git to them.

na85 10y ago

I don't like git because I have zero confidence that it won't do something dumb like fail to diff properly requiring me to merge 980 diffs in a single file while it puts the <<<<<<<< and >>>>>>>> markers in the wrong places, randomly transposing lines from one part of a file to another for no discernible reason. You know, like happened to me today.

deleted 10y ago
[deleted]

CJefferson 10y ago

Some reasons I don't like git, straight off the top of my head. * Some commands require remote branch, others require remote/branch. I can never remember which. * git lets you create branches with names like 'remote/branch', at which point it starts going crazy because when I then write remote/branch, it doesn't know if I mean branch on remote, or the local branch remote/branch. * When merging / rebasing goes wrong, it can be hard (or impossible) to recover back to the state I started from.

jcranmer 10y ago

My first experience with a VCS was using Mercurial, about a decade ago. In that time, I've only had at most three or four instances where I so borked the repository that I had to destroy it and start again. This includes the time when I didn't know anything about VCS and was liable to foot-gun myself. I probably first used Git about 5, 6 years ago, and, despite using it at a much reduced frequency (virtually all my git usage is via hg-git nowadays), I've easily had a dozen times where it was easier to blow away a repository than fix it. Obviously, heavy prior experience with Mercurial does color one's views about UX, but the experience with Git that I have had--and that I have seen many others concur with--is that the UX makes it way too easy to get you in states that you don't know what to do. But that's not the biggest flaw with Git. The biggest flaw is the community: when you don't know what to do, and you start trying to find the answer, instead of being told "this is how you fix it," you instead get a lecture on the full internals of Git, and why the crazy incantation should be really obvious to any user. Is it any surprise that one would find it easier to blow away the directory and recreate the five-line build system fix whose merge conflict caused the mess in the first place? Your comment is a picture-perfect of this community hostility that I see with Git that I don't see with other VCS. There definitely seems to be a sentiment that there is One True Way™ to do things, and if you're not doing it like that, you are wrong. I care to disagree: a VCS is a tool--it should support my workflow, not dictate it. I find that the community around Mercurial is much more in agreement with the philosophy I hold, and unsurprisingly, I've generally found Mercurial to be superior than Git.