5 ms·

> while you try to figure out the arcane git command for something that I was done with in Mercurial hours ago I sense a lot of resentment in this statement, b

> while you try to figure out the arcane git command for something that I was done with in Mercurial hours ago I sense a lot of resentment in this statement, but to be honest I have no idea what people are talking about when it comes to their gripes against Git. Little goes wrong, and when anything does, fixing it is a reflog or a reset away. I could understand being frustrated trying to jump right into it, especially with the interface as of the mid-late oughts, but it's fairly straightforward these days. The defaults make sense, and the built-in tools are consistent and plentiful. I doubt I could compose a correct filter-branch from memory, but I don't even think I could find an example for Mercurial, and I doubt the manpage would be as helpful.

bsder 9y ago
> but to be honest I have no idea what people are talking about when it comes to their gripes against Git. Little goes wrong, and when anything does, fixing it is a reflog or a reset away. I will be happy to call you the next time one of my devs does something that causes git to wedge itself into one of those states. It happens about every 2 weeks--and I suspect that it happens more frequently than that. Normally I can unwedge git after reading approximately 10 git pages all claiming to fix my problem (they don't but they probably point me at the brain-damaged command I need). Most of the time ... about once every 3 months everything fails and we have to pull a backup. Fortunately, the devs have now been brainwashed to rsync the repository on at least a daily basis and always before they do anything besides a basic checkout or commit. But, hey, they're using git, and it's what everybody else uses. As someone who uses Mercurial and does some pretty hairy stuff with it, I have never put the system into a wedged state. NEVER. The only time I saw a Mercurial repo get wedged was when the underlying filesystem barfed on itself. Yeah, I'm a touch sore about this because I regularly get to fix problems that WOULD NOT EXIST if the team was in Mercurial instead of git. However, as a manager who likes to think of himself as "good", I cannot force tools on a team unless they actually do measurable damage. I also get sore with the "Well, if you only understood the git model..." I DO understand the git model--much to my horror. The problem is that while a newbie can learn the Mercurial model in about 60 seconds and be productive the git model takes about 60 months to learn and they will still regularly footgun themselves.
- stevekemp 9y ago
  So you've repeated your assertion that "people break git" and that fixing it "is hard". It seems surprising that so many people, familiar with daily use, manage to keep breaking things in your environment, but others here don't. Have you written bug reports? Or documented the nature of these broken states? 90% of the git users probably just run a handful of commands. ("git status", "git add", "git diff", "git commit", and creating/merging branches). Those commands seem unlikely to cause widespread problems, but perhaps you're doing something else?
- gjulianm 9y ago
  Just out of curiosity, which states do your developers put git in? I’ve worked with people that were learning git and the worst they’ve done is committing files with conflicts after a merge or putting in files that should be ignored. Oh, and one guy who force pushed to a repo and made the CI system refuse to pull the changes until I reset the repo there.
curun1r 9y ago
> fixing it is a reflog or a reset away Only for people who have internalized what GP called "git's totally brain damaged use of source control concepts." When you don't understand the structure of the underlying database that Git uses, the error messages that Git returns might as well be in Greek for all the help they provide. Mercurial has mostly the same concepts as Git but the developers have taken the time to translate the error messages that are returned to users into words that actually explain what the problem is and how you might go about fixing it. In my experience with Git, there's two ways to be productive with it. The first is to go read Git source code and basically understand exactly how each command you issue is changing the data in your repository. I eventually resorted to this strategy the umpteenth time that I managed to get my repo into some bizarre state that I'd never seen before. The other solution is to ensure that the entire team sticks to a very precise subset of what Git provides and be pretty militant about limiting everyone to those blessed incantations. Git flow is pretty useful for this since adherence to the steps generally keeps a Git repo in working order. I generally try to follow this second strategy since following the first means that you become the "Git guy" at work that everyone turns to when they've managed to get in over their heads. Also, mostly unrelated, but when I work in Git, I miss hg serve. Being able to pull changes from/to colleagues using zeroconf without needing to set them up as a remote was really useful. I know Git has instaweb, but it's an incomplete solution and just another example of where using Git just has a lot more friction than the more pleasant hg experience.
- radarsat1 9y ago
  > When you don't understand the structure of the underlying database that Git uses For me this is totally exactly true for Mercurial. I find git's underlying model way easier to understand. Mercurial with its 3 different branching representations (branches, bookmarks, patch queues..) and "state tracking" is really quite a bit more complicated and I do not find it is easier to internalize; quite the opposite, as a git user I have found it extremely difficult to contribute to hg-based projects for this reason. For me, git is just a tree and pointers to nodes on that tree. I find it hard to see how it is difficult to understand.
  - hvidgaard 9y ago

bsder 9y ago

> but to be honest I have no idea what people are talking about when it comes to their gripes against Git. Little goes wrong, and when anything does, fixing it is a reflog or a reset away. I will be happy to call you the next time one of my devs does something that causes git to wedge itself into one of those states. It happens about every 2 weeks--and I suspect that it happens more frequently than that. Normally I can unwedge git after reading approximately 10 git pages all claiming to fix my problem (they don't but they probably point me at the brain-damaged command I need). Most of the time ... about once every 3 months everything fails and we have to pull a backup. Fortunately, the devs have now been brainwashed to rsync the repository on at least a daily basis and always before they do anything besides a basic checkout or commit. But, hey, they're using git, and it's what everybody else uses. As someone who uses Mercurial and does some pretty hairy stuff with it, I have never put the system into a wedged state. NEVER. The only time I saw a Mercurial repo get wedged was when the underlying filesystem barfed on itself. Yeah, I'm a touch sore about this because I regularly get to fix problems that WOULD NOT EXIST if the team was in Mercurial instead of git. However, as a manager who likes to think of himself as "good", I cannot force tools on a team unless they actually do measurable damage. I also get sore with the "Well, if you only understood the git model..." I DO understand the git model--much to my horror. The problem is that while a newbie can learn the Mercurial model in about 60 seconds and be productive the git model takes about 60 months to learn and they will still regularly footgun themselves.

stevekemp 9y ago
So you've repeated your assertion that "people break git" and that fixing it "is hard". It seems surprising that so many people, familiar with daily use, manage to keep breaking things in your environment, but others here don't. Have you written bug reports? Or documented the nature of these broken states? 90% of the git users probably just run a handful of commands. ("git status", "git add", "git diff", "git commit", and creating/merging branches). Those commands seem unlikely to cause widespread problems, but perhaps you're doing something else?
gjulianm 9y ago
Just out of curiosity, which states do your developers put git in? I’ve worked with people that were learning git and the worst they’ve done is committing files with conflicts after a merge or putting in files that should be ignored. Oh, and one guy who force pushed to a repo and made the CI system refuse to pull the changes until I reset the repo there.

curun1r 9y ago

> fixing it is a reflog or a reset away Only for people who have internalized what GP called "git's totally brain damaged use of source control concepts." When you don't understand the structure of the underlying database that Git uses, the error messages that Git returns might as well be in Greek for all the help they provide. Mercurial has mostly the same concepts as Git but the developers have taken the time to translate the error messages that are returned to users into words that actually explain what the problem is and how you might go about fixing it. In my experience with Git, there's two ways to be productive with it. The first is to go read Git source code and basically understand exactly how each command you issue is changing the data in your repository. I eventually resorted to this strategy the umpteenth time that I managed to get my repo into some bizarre state that I'd never seen before. The other solution is to ensure that the entire team sticks to a very precise subset of what Git provides and be pretty militant about limiting everyone to those blessed incantations. Git flow is pretty useful for this since adherence to the steps generally keeps a Git repo in working order. I generally try to follow this second strategy since following the first means that you become the "Git guy" at work that everyone turns to when they've managed to get in over their heads. Also, mostly unrelated, but when I work in Git, I miss hg serve. Being able to pull changes from/to colleagues using zeroconf without needing to set them up as a remote was really useful. I know Git has instaweb, but it's an incomplete solution and just another example of where using Git just has a lot more friction than the more pleasant hg experience.

radarsat1 9y ago
> When you don't understand the structure of the underlying database that Git uses For me this is totally exactly true for Mercurial. I find git's underlying model way easier to understand. Mercurial with its 3 different branching representations (branches, bookmarks, patch queues..) and "state tracking" is really quite a bit more complicated and I do not find it is easier to internalize; quite the opposite, as a git user I have found it extremely difficult to contribute to hg-based projects for this reason. For me, git is just a tree and pointers to nodes on that tree. I find it hard to see how it is difficult to understand.
- hvidgaard 9y ago