3 ms·

The idea is that that mental model isn't a very useful and error-proof one. Saying "well that's the mental model" doesn't evade criticism of the mental model.

by ajkjk 6y ago

ajross 6y ago
But it's not criticism of the mental model, it's criticism that fails to recognize there are models that fit the problem better. Again, changing a branch and preserving your work is sequence of two commands; two very obvious commands applied in the obvious way, no less. You learn what a "branch" is in git and then you don't have problem. The problem with the linked article is that it's trying to understand a "branch" to mean something like a "working area" or a "checked out directory" or something. And that's just a different mental model. And getting to the criticism in the linked article, it's a very non-orthogonal model, polluting the idea of a "working tree" (which in git just means "the filesystem contents") with weird metadata about where the files "came from".
- ajkjk 6y ago
  > it's criticism that fails to recognize I really don't think that's the right interpretation. This is a direct criticism of the correct mental model for Git. In essence is says "This model, although functional, is way more complex than it needs to be. Here is a simpler model that accomplishes the same goals with less confusion for beginners and experienced users alike." I don't see a great argument for the concept of un-committed changes existing at all, and the tool would be a lot easier if they didn't. My implementation would be for every local change to be immediately amended onto HEAD, and then `git commit` creates a new empty commit for subsequent changes to attach to. If you want to not include a file, exclude it. Or something like that, I haven't thought about it in detail really.
  - ajross 6y ago
    > "This model, although functional, is way more complex than it needs to be. And I don't see how that statement is consistent with: # First Understand "branches are commits" $ git commit -a -m WIP $ git checkout $NEW_BRANCH I just don't, sorry. Trivial concept. Trivial composition of two commands you use all the time. Orthogonal. Clean. Straightforward. There are areas (c.f. the index, which I talked about upthread) where git does make excessive demands on the new learner. This is simply not one. Sorry. What the linked article wants to see is objectively a more complicated UI based on an incorrect understanding[1] of what a git branch is. [1] Which is weird, because git's idea of "working on a branch" is fundamentally unchanged from the legacy handed down from SCCS, RCS, CVS and subversion. NONE of those tools ever did this!
    - ajkjk 6y ago
      I dunno what to tell you. I just don't think it's a good model. I've obviously learned to deal with it, but every time I have to type two commands instead of one to do that, I think: it's a shame this was designed like this and is so hard to change now.
    - tsimionescu 6y ago
      You're showing the stashing part, but disregarding what happens when you get back to the original work. You now have to either git reset or git ammend or git squash later and so on. Oh, and if you want to edit the commit PRIOR to the WIP one, you need to do several of these, simce only the latest commit can be eaisly edited. And the alternative in something like P4? cd ../other-branch # do some work cd ../first-branch Vs the git solution: git commit -a -m WIP git checkout other_branch # hopefully you didn't have any untracked files that you meant to add on both branches #do some work git checkout first_branch git reset -s first_branch~1 Sure, it's not THAT hard, but it's still much harder than it needs to be, it's harder to learn, easier to mess up and takes far more time (git checkout is not an instantaneous operation, unlike cd). Not to mention, there are at least 4 ways to do this, with slightly different trade-offs, further increasing the mental load. Edit: oh, and let's not forget that sometimes you want to actually compile and run and debug two different versionsof your product, and then the git model completely breaks down.

The idea is that that mental model isn't a very useful and error-proof one. Saying "well that's the mental model" doesn't evade criticism of the mental model.

by ajkjk 6y ago

The idea is that that mental model isn't a very useful and error-proof one. Saying "well that's the mental model" doesn't evade criticism of the mental model.

ajross 6y ago

But it's not criticism of the mental model, it's criticism that fails to recognize there are models that fit the problem better. Again, changing a branch and preserving your work is sequence of two commands; two very obvious commands applied in the obvious way, no less. You learn what a "branch" is in git and then you don't have problem. The problem with the linked article is that it's trying to understand a "branch" to mean something like a "working area" or a "checked out directory" or something. And that's just a different mental model. And getting to the criticism in the linked article, it's a very non-orthogonal model, polluting the idea of a "working tree" (which in git just means "the filesystem contents") with weird metadata about where the files "came from".

ajkjk 6y ago
> it's criticism that fails to recognize I really don't think that's the right interpretation. This is a direct criticism of the correct mental model for Git. In essence is says "This model, although functional, is way more complex than it needs to be. Here is a simpler model that accomplishes the same goals with less confusion for beginners and experienced users alike." I don't see a great argument for the concept of un-committed changes existing at all, and the tool would be a lot easier if they didn't. My implementation would be for every local change to be immediately amended onto HEAD, and then `git commit` creates a new empty commit for subsequent changes to attach to. If you want to not include a file, exclude it. Or something like that, I haven't thought about it in detail really.
- ajross 6y ago
  > "This model, although functional, is way more complex than it needs to be. And I don't see how that statement is consistent with: # First Understand "branches are commits" $ git commit -a -m WIP $ git checkout $NEW_BRANCH I just don't, sorry. Trivial concept. Trivial composition of two commands you use all the time. Orthogonal. Clean. Straightforward. There are areas (c.f. the index, which I talked about upthread) where git does make excessive demands on the new learner. This is simply not one. Sorry. What the linked article wants to see is objectively a more complicated UI based on an incorrect understanding[1] of what a git branch is. [1] Which is weird, because git's idea of "working on a branch" is fundamentally unchanged from the legacy handed down from SCCS, RCS, CVS and subversion. NONE of those tools ever did this!
  - ajkjk 6y ago
    I dunno what to tell you. I just don't think it's a good model. I've obviously learned to deal with it, but every time I have to type two commands instead of one to do that, I think: it's a shame this was designed like this and is so hard to change now.
  - tsimionescu 6y ago
    You're showing the stashing part, but disregarding what happens when you get back to the original work. You now have to either git reset or git ammend or git squash later and so on. Oh, and if you want to edit the commit PRIOR to the WIP one, you need to do several of these, simce only the latest commit can be eaisly edited. And the alternative in something like P4? cd ../other-branch # do some work cd ../first-branch Vs the git solution: git commit -a -m WIP git checkout other_branch # hopefully you didn't have any untracked files that you meant to add on both branches #do some work git checkout first_branch git reset -s first_branch~1 Sure, it's not THAT hard, but it's still much harder than it needs to be, it's harder to learn, easier to mess up and takes far more time (git checkout is not an instantaneous operation, unlike cd). Not to mention, there are at least 4 ways to do this, with slightly different trade-offs, further increasing the mental load. Edit: oh, and let's not forget that sometimes you want to actually compile and run and debug two different versionsof your product, and then the git model completely breaks down.