6 ms·

"The mental model for Git is needlessly complex and consequently distracts attention from software under development. A user of Git needs to keep all of the fol

by vangar 8y ago

"The mental model for Git is needlessly complex and consequently distracts attention from software under development. A user of Git needs to keep all of the following in mind: The working directory The "index" or staging area The local head The local copy of the remote head The actual remote head Git contains commands (or options on commands) for moving and comparing content between all of these locations. In contrast, Fossil users only need to think about their working directory and the check-in they are working on. That is 60% less distraction." I don't think about any of this when developing. I check out a branch, work on it, commit to it, and push it back up. If the fix is larger than a few commits i'll make a feature branch. What's so hard about that? Also, everyone using git isn't a bad thing. It means we finally have at least one standard in development.

wvenable 8y ago
I feel like everyone using git is like everyone using C.
- dimman 8y ago
  Fortunately for us C programmers then that not everyone has come to their senses.
psyc 8y ago
You get git. Good for you. A lot of smart people get git. A lot of smart people don't. I'm a smart person. I use git every day, 7 days a week. On my side projects, it's fine. Never a problem. At work, the workflow is more complicated, due to many branches, and many submodules. Submodules are a pain in practice. I think the mental model is too complex. This manifests as frequent unintended results, from simple operations that in my mind need not have unintended consequences. I never had any such problem with Perforce, even though I have used git twice as long. Your mileage obviously varies.
- kadenshep 8y ago
  >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 8y 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 8y 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 8y 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.
skybrian 8y ago
This is fine when you're working on your own project. However, if you want to send a patch to someone else's project on Github, you have to create a remote fork, download the fork, and push it to your remote fork, then send the pull request. (I have tried other ways but they don't seem to work.) This is fairly annoying since it's extra steps and it clutters many people's Github accounts with forked versions of projects they contribute to. There's no good reason for these forks to exist. But this is a problem with Github and not git itself.
- kbsletten 8y ago
  On the other hand, do you really want random people on the internet to be able to inject objects into your git repository by creating a branch or whatever? Especially after SHAttered, that's a huge liability that sort-of justifies the "you take yours and go over there" approach.
  - skybrian 8y ago
    Of course not. You want to send them a patch and have it show up in their "inbox" on Github as a pull request. There's no reason to put pull requests into the git repo.
fulafel 8y ago
A majority of VCS users don't use them in a write-only way.
lozenge 8y ago
I normally use git commit -a. I use git diff to preview my commit. However, recently I had to git add a file. After that, git diff didn't show the file, even though git commit did include it in the commit. So, it doesn't take long to realise that you need to understand the index after all. You need to learn git add -N, or use "git diff HEAD" instead of git diff.

by vangar 8y ago

wvenable 8y ago

I feel like everyone using git is like everyone using C.

dimman 8y ago
Fortunately for us C programmers then that not everyone has come to their senses.

psyc 8y ago

You get git. Good for you. A lot of smart people get git. A lot of smart people don't. I'm a smart person. I use git every day, 7 days a week. On my side projects, it's fine. Never a problem. At work, the workflow is more complicated, due to many branches, and many submodules. Submodules are a pain in practice. I think the mental model is too complex. This manifests as frequent unintended results, from simple operations that in my mind need not have unintended consequences. I never had any such problem with Perforce, even though I have used git twice as long. Your mileage obviously varies.

kadenshep 8y ago
>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 8y 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 8y 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 8y 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.

skybrian 8y ago

This is fine when you're working on your own project. However, if you want to send a patch to someone else's project on Github, you have to create a remote fork, download the fork, and push it to your remote fork, then send the pull request. (I have tried other ways but they don't seem to work.) This is fairly annoying since it's extra steps and it clutters many people's Github accounts with forked versions of projects they contribute to. There's no good reason for these forks to exist. But this is a problem with Github and not git itself.

kbsletten 8y ago
On the other hand, do you really want random people on the internet to be able to inject objects into your git repository by creating a branch or whatever? Especially after SHAttered, that's a huge liability that sort-of justifies the "you take yours and go over there" approach.
- skybrian 8y ago
  Of course not. You want to send them a patch and have it show up in their "inbox" on Github as a pull request. There's no reason to put pull requests into the git repo.

fulafel 8y ago

A majority of VCS users don't use them in a write-only way.

lozenge 8y ago

I normally use git commit -a. I use git diff to preview my commit. However, recently I had to git add a file. After that, git diff didn't show the file, even though git commit did include it in the commit. So, it doesn't take long to realise that you need to understand the index after all. You need to learn git add -N, or use "git diff HEAD" instead of git diff.