5 ms·

>A lot of smart people don't. I'm sorry, I don't buy this at all. Git is one of the most simple source control tools there is. If you can't understand a DAG th

>A lot of smart people don't. I'm sorry, I don't buy this at all. Git is one of the most simple source control tools there is. If you can't understand a DAG then there isn't much else you probably can understand in the development world. >This manifests as frequent unintended results No it doesn't. Every time I've seen people complain about "unintended results" it's literally been because of the above, and they've been complete morons so I'm never surprised when these people have "trouble" with git. You're building a graph, and you're doing pretty basic manipulation of that graph. >I never had any such problem with Perforce Uh what? Permission issues? Terrible branch performance? Merging between branches is basically a gamble -- it's actually insane how much this used to mess up over the most basic of merges. Having to "upgrade" the system? Ever done that. I'm going to guess no.

viraptor 9y ago
Please don't be that guy. You saw people having issues with git. Have you tried explaining why they ran into those problems and tried to find out where the misunderstanding came from? It's easy to criticise about what you already know. But everybody's experience is different. There's a practical issue with mapping every command to each copy of the dag, that people sometimes don't get. If you haven't learned about urbit yet, you could try that for the same "I don't know what you're talking about" experience in your life.
- kadenshep 9y ago
  > Have you tried explaining why they ran into those problems and tried to find out where the misunderstanding came from? Of course? I'm also free to call them idiots online. >There's a practical issue with mapping every command to each copy of the dag That is certainly the most valid criticism of git, in my opinion. And certainly the biggest learning curve for most people. But that's not where people tend to have true, blue operational issues in my experience.
keithnz 9y ago
This is why some devs shouldn't design UIs, for many people their source control is simply a UI that they want simple with simple workflows. I know people with PhDs who just don't understand git, not because they can't understand DAG, they simply don't want to have to understand it in relation to a tool. The biggest thing with Git is you have to invest time into understanding it, that alone is one of its failings and hence why there is so so so many guides that try to give advice to people who don't really want to understand it.
- kadenshep 9y ago
  >they simply don't want to have to understand it in relation to a tool. There isn't a way around this. With any tool, especially when dealing with SCM. You have to understand how your selected tool is going to perform certain operations because it's going to dramatically effect your workflow with that tool. >The biggest thing with Git is you have to invest time into understanding it Just like you have to do with every other SCM, or just generally any piece of software?
  - zaphar 9y ago
    The difference is that most other SCM's don't actively lose your work while you are learning.
    - kadenshep 9y ago
      Git doesn't do that. Perforce and TFS definitely will. The very moment I add something to the index it's basically recoverable. I'm not sure what you're really getting at here.
      - luckydude 9y ago
        So I'd like you to prove that git won't lose work. Even smart people who use git have typed stuff that made them lose work. You can, and will, argue they are morons. That's an excellent way to deal with a poorly designed system.
zaphar 9y ago
I can run circles around most of my fellow developers working with Git. I know how to recover from almost anything I do with Git. However, I put in a lot of hours to get there. I have nothing but distaste for Git's command line. It's an abomination. The command line flags are inconsistent and require real work to commit the right combinations to memory. Anyone, whose solution to this is "You are an idiot for getting confused by this confusing UI" is just flat out wrong. There are better UI's that are less confusing with the same featureset as Git. Git won not because it was that much better than the others. It won because the Linux kernel uses it. Right now today, there are developers out there who are putting in the work to learn git. They are smart and dedicated to their craft. They are also losing work because git makes it easy to shoot yourself in the foot and because it doesn't easily surface to you how to recover when you do so. It's not because the developer is an "idiot". It's because git's UI is user hostile and does a poor job of reflecting the core concepts in operation when the user is using it. To be fair to Git they've put a lot of effort in fixing this. It used to far worse than it is now. But due to backwards compatibility and other concerns there is still a lot confusing and unintelligible options out there and that is even after you get the whole concept of a DAG and the index vs working tree.
- kadenshep 9y ago
  > Git won not because it was that much better than the others. It won because the Linux kernel uses it. This is a pretty silly assertion to make. You're actively ignoring the SCM's that were chosen by far larger org's. Git took the dev world by storm because it was better. Not because an open source OS used it. Other SCM's had years worth of developer training and interaction with their systems and STILL lost. Years worth of sales connections, demos, networking, you name it and STILL lost. >They are also losing work because git makes it easy to shoot yourself in the foot Example?
  - mkgolden 9y ago
    I would like to hear some examples as well. I hate losing my work.
  - cookiecaper 9y ago

viraptor 9y ago

Please don't be that guy. You saw people having issues with git. Have you tried explaining why they ran into those problems and tried to find out where the misunderstanding came from? It's easy to criticise about what you already know. But everybody's experience is different. There's a practical issue with mapping every command to each copy of the dag, that people sometimes don't get. If you haven't learned about urbit yet, you could try that for the same "I don't know what you're talking about" experience in your life.

kadenshep 9y ago
> Have you tried explaining why they ran into those problems and tried to find out where the misunderstanding came from? Of course? I'm also free to call them idiots online. >There's a practical issue with mapping every command to each copy of the dag That is certainly the most valid criticism of git, in my opinion. And certainly the biggest learning curve for most people. But that's not where people tend to have true, blue operational issues in my experience.

keithnz 9y ago

This is why some devs shouldn't design UIs, for many people their source control is simply a UI that they want simple with simple workflows. I know people with PhDs who just don't understand git, not because they can't understand DAG, they simply don't want to have to understand it in relation to a tool. The biggest thing with Git is you have to invest time into understanding it, that alone is one of its failings and hence why there is so so so many guides that try to give advice to people who don't really want to understand it.

kadenshep 9y ago
>they simply don't want to have to understand it in relation to a tool. There isn't a way around this. With any tool, especially when dealing with SCM. You have to understand how your selected tool is going to perform certain operations because it's going to dramatically effect your workflow with that tool. >The biggest thing with Git is you have to invest time into understanding it Just like you have to do with every other SCM, or just generally any piece of software?
- zaphar 9y ago
  The difference is that most other SCM's don't actively lose your work while you are learning.
  - kadenshep 9y ago
    Git doesn't do that. Perforce and TFS definitely will. The very moment I add something to the index it's basically recoverable. I'm not sure what you're really getting at here.
    - luckydude 9y ago
      So I'd like you to prove that git won't lose work. Even smart people who use git have typed stuff that made them lose work. You can, and will, argue they are morons. That's an excellent way to deal with a poorly designed system.

zaphar 9y ago

I can run circles around most of my fellow developers working with Git. I know how to recover from almost anything I do with Git. However, I put in a lot of hours to get there. I have nothing but distaste for Git's command line. It's an abomination. The command line flags are inconsistent and require real work to commit the right combinations to memory. Anyone, whose solution to this is "You are an idiot for getting confused by this confusing UI" is just flat out wrong. There are better UI's that are less confusing with the same featureset as Git. Git won not because it was that much better than the others. It won because the Linux kernel uses it. Right now today, there are developers out there who are putting in the work to learn git. They are smart and dedicated to their craft. They are also losing work because git makes it easy to shoot yourself in the foot and because it doesn't easily surface to you how to recover when you do so. It's not because the developer is an "idiot". It's because git's UI is user hostile and does a poor job of reflecting the core concepts in operation when the user is using it. To be fair to Git they've put a lot of effort in fixing this. It used to far worse than it is now. But due to backwards compatibility and other concerns there is still a lot confusing and unintelligible options out there and that is even after you get the whole concept of a DAG and the index vs working tree.

kadenshep 9y ago
> Git won not because it was that much better than the others. It won because the Linux kernel uses it. This is a pretty silly assertion to make. You're actively ignoring the SCM's that were chosen by far larger org's. Git took the dev world by storm because it was better. Not because an open source OS used it. Other SCM's had years worth of developer training and interaction with their systems and STILL lost. Years worth of sales connections, demos, networking, you name it and STILL lost. >They are also losing work because git makes it easy to shoot yourself in the foot Example?
- mkgolden 9y ago
  I would like to hear some examples as well. I hate losing my work.
- cookiecaper 9y ago