4 ms·

I feel that people that rail on "git checkout" don't actually understand what it does. It does two things: 1) unpacks files from the repository into the working

I feel that people that rail on "git checkout" don't actually understand what it does. It does two things: 1) unpacks files from the repository into the working directory, and 2) updates the current working branch. Want to revert your changes? That's unpacking from the repo to the working dir. Want to switch to a different branch? That's also unpacking files from the repo to the working dir. The only difference is that in one case the current working branch stays the same and in one case it changes (or you could look at it as in one case you set it to the current value and in the other you set it to something different). This is why people say you need to understand the underlying model of git to grok it. The commands make perfect sense from the perspective of the data model. Also, want to create a branch? "git branch new-branch". Delete it "git branch -d new-branch". The "checkout -b" is an optimization, just like "rm -r x" is an optimization of "find x | xargs rm" (why do two commands when you can do one?). The only thing I don't like about git UI is that it can't decide what to call the "index". It's called "index", "staging area", and "cache" in various places (including command line flags), which is confusing.

jordigh 13y ago
> This is why people say you need to understand the underlying model of git to grok it. The commands make perfect sense from the perspective of the data model. Making people understand the internal data structures in order to understand a UI is... not good.
- rcxdude 13y ago
  It's not 'internal'. It's the model it presents to the user. Internal would be needing to know how the blob file format works.
- edavis 13y ago
  See, but I don't think they're "internal" at all. The "underlying model of git" that David refers to (blobs, trees, commits, tags, branches, HEAD, etc.) aren't seen as internal data structures to be glossed over by a UI. They're the very essence of git.
  - rkwz 13y ago
    > The "underlying model of git" that David refers to (blobs, trees, commits, tags, branches, HEAD, etc.) aren't seen as internal data structures to be glossed over by a UI. They're the very essence of git. Users don't need to know the 'very essence' of a tool inorder to use it. Do you think that people who drive cars know in detail about how car works? They just need to know about starting a car, making it go forward, backward, parking etc and that's what most car drivers care about.
    - mhw 13y ago
      It's not all that helpful to compare version control tools with cars, I don't think. Users of a version control tool do need to know about branches, tags, commits and such because they are the heart of what version control is. If you've ever seen an environment where version control tooling has been introduced without the support of the developers you'll have seen what happens when you treat it like a car: empty check in messages, commits getting clobbered by "I'll jut check in my version" merges, and contention over file locks in tools where locking was part of the model.
    - __david__ 13y ago
      You don't have to understand how a carburetor works to drive a car, but you do have to know that "Drive" connects the engine to the wheels. Git is like driving a manual transmission. In a manual car you have to understand that the clutch disengages the motor from the drive shaft and how the different gears work in general. It's not rocket science and most people can pick it up.
      - masklinn 13y ago
        > Git is like driving a manual transmission. Git is nothing like driving manual. > In a manual car you have to understand that the clutch disengages the motor from the drive shaft and how the different gears work in general. No, you most definitely don't, that's complete lunacy. The vast majority of (manual) drivers[0] have no idea how things work and they don't give a fuck. Different gears are for "go faster" and "go slower", and the clutch is for "change gear". People learn to do it right because the alternative is to stall or get a horrible grinding sound and pay top bucks to get stuff fixed, not because they understand how things work under the hood. [0] in countries where it's the norm, not in countries like the US where manual is for nerds and passioned
barrkel 13y ago
The thing I find unpleasant with git is the inconsistency of commands. Why git branch -d for deleting branches, but git remote rm for deleting remotes? Etc. As to git's basic model - a dag of commits, with branches being little more than auto-updating labels for commits - that fit into place in the first 5 minutes of usage. My learning time with git was shorter than any previous source control I used, except for sourcesafe, in so far as that is a SCM.

jordigh 13y ago

> This is why people say you need to understand the underlying model of git to grok it. The commands make perfect sense from the perspective of the data model. Making people understand the internal data structures in order to understand a UI is... not good.

rcxdude 13y ago
It's not 'internal'. It's the model it presents to the user. Internal would be needing to know how the blob file format works.
edavis 13y ago
See, but I don't think they're "internal" at all. The "underlying model of git" that David refers to (blobs, trees, commits, tags, branches, HEAD, etc.) aren't seen as internal data structures to be glossed over by a UI. They're the very essence of git.
- rkwz 13y ago
  > The "underlying model of git" that David refers to (blobs, trees, commits, tags, branches, HEAD, etc.) aren't seen as internal data structures to be glossed over by a UI. They're the very essence of git. Users don't need to know the 'very essence' of a tool inorder to use it. Do you think that people who drive cars know in detail about how car works? They just need to know about starting a car, making it go forward, backward, parking etc and that's what most car drivers care about.
  - mhw 13y ago
    It's not all that helpful to compare version control tools with cars, I don't think. Users of a version control tool do need to know about branches, tags, commits and such because they are the heart of what version control is. If you've ever seen an environment where version control tooling has been introduced without the support of the developers you'll have seen what happens when you treat it like a car: empty check in messages, commits getting clobbered by "I'll jut check in my version" merges, and contention over file locks in tools where locking was part of the model.
  - __david__ 13y ago
    You don't have to understand how a carburetor works to drive a car, but you do have to know that "Drive" connects the engine to the wheels. Git is like driving a manual transmission. In a manual car you have to understand that the clutch disengages the motor from the drive shaft and how the different gears work in general. It's not rocket science and most people can pick it up.
    - masklinn 13y ago
      > Git is like driving a manual transmission. Git is nothing like driving manual. > In a manual car you have to understand that the clutch disengages the motor from the drive shaft and how the different gears work in general. No, you most definitely don't, that's complete lunacy. The vast majority of (manual) drivers[0] have no idea how things work and they don't give a fuck. Different gears are for "go faster" and "go slower", and the clutch is for "change gear". People learn to do it right because the alternative is to stall or get a horrible grinding sound and pay top bucks to get stuff fixed, not because they understand how things work under the hood. [0] in countries where it's the norm, not in countries like the US where manual is for nerds and passioned

barrkel 13y ago

The thing I find unpleasant with git is the inconsistency of commands. Why git branch -d for deleting branches, but git remote rm for deleting remotes? Etc. As to git's basic model - a dag of commits, with branches being little more than auto-updating labels for commits - that fit into place in the first 5 minutes of usage. My learning time with git was shorter than any previous source control I used, except for sourcesafe, in so far as that is a SCM.