5 ms·

There are two things people mean when they say Git is complicated. Some people mean that Git's model is complicated, which what you're talking about. I actual

by gecko 12y ago

There are two things people mean when they say Git is complicated. Some people mean that Git's model is complicated, which what you're talking about. I actually find its model very simple, some people find it complicated, but at any rate, I certainly think Git and Mercurial have comparable complexity in the model. What most people mean, though, is that Git's UI is complicated. To be blunt, I think this is simply objectively correct. For example, "git checkout foo" might mean go to the foo branch, or might mean revert a file called "foo". There is no way to know. If you want to be sure to revert a file called foo, you can do "git checkout -- foo", I believe, but I don't know a branch equivalent (and it at any rate won't be symmetrical). Want to create a new branch? That's "git checkout -b newbranch". Want to delete it? That's "git branch -d newbranch". There are tons of things like this in the Git UI, where commands have basically arbitrary parameters in different contexts. Way back when Git was first created, the plan was for what is now called Git to be the underlying implementation of a higher-level UI. I really, profoundly wish that had actually panned out. Instead, Git's low-level commands gradually grew more user-friendly until it hit the "good enough" zone. That's what people usually mean when they say Git's complicated.

__david__ 12y ago
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 12y 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 12y 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 12y 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 12y 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 12y 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.
tieTYT 12y ago
Your complaints seem like a very indirect way to get what you want. Perhaps it's git's fault for making these possibilities, but I didn't even know they exist. If you want to revert/reset a file, why don't you just use the reset command? That seems like a more direct way than using checkout. If you want to create a new branch, why not use "git branch branch-name"? As another said, the "git checkout -b branch-name" is just shorthand for convenience. I've been learning git over a mere 2 months (I came from svn), I'm finding its UI to be very pleasant. As someone else said, that index/staging/cached situation is bad, though.
- pfranz 12y ago
  "If you want to revert/reset a file, why don't you just use the reset command? That seems like a more direct way than using checkout." Because that's what git tell you to do when you run "git status" # (use "git checkout -- <file>..." to discard changes in working directory)
- gecko 12y ago
  Interesting you should mention "git reset", because, depending on the options you give it, it either: * reverts one file * reverts all files * removes changes from the index, but doesn't otherwise change anything at all * moves your branch, without changing any files * moves your branch and changes all files This rather makes my point. "git checkout -b", meanwhile, is not a shorthand for "git branch something", but rather "git branch --track something origin/something", unless there is no "origin/something", in which case you are again correct.
russelldavis 12y ago
The branch equivalent is `git checkout foo --`. I wrote a simple shell script[1] that makes that the default, requiring you to do `-- <file>` for files, so there's never a possibility of ambiguity. [1] https://gist.github.com/russelldavis/e5173ce1269fae67baaf https://gist.github.com/russelldavis/e5173ce1269fae67baaf
sampo 12y ago
> "the plan was for what is now called Git to be the underlying implementation of a higher-level UI" Some time around year 1960, the plan was to develop a language with syntax ("M-expressions") on top of the Lisp S-expressions. We are still waiting, I guess. http://www-formal.stanford.edu/jmc/history/lisp/node3.html http://www-formal.stanford.edu/jmc/history/lisp/node3.html
qrohlf 12y ago
Relevant: http://stevelosh.com/blog/2013/04/git-koans/ http://stevelosh.com/blog/2013/04/git-koans/
rkwz 12y ago
> Way back when Git was first created, the plan was for what is now called Git to be the underlying implementation of a higher-level UI. Has anyone attempted to actually implement this? Building a 'VCS' on top of git but with a simple 'UI'?
- skrause 12y ago
  http://en.wikipedia.org/wiki/Cogito_(software) http://en.wikipedia.org/wiki/Cogito_(software)
- gammarator 12y ago
  EasyGit, and others: https://people.gnome.org/~newren/eg/ https://people.gnome.org/~newren/eg/

by gecko 12y ago

__david__ 12y ago

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 12y 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 12y 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 12y 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 12y 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 12y 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.

tieTYT 12y ago

Your complaints seem like a very indirect way to get what you want. Perhaps it's git's fault for making these possibilities, but I didn't even know they exist. If you want to revert/reset a file, why don't you just use the reset command? That seems like a more direct way than using checkout. If you want to create a new branch, why not use "git branch branch-name"? As another said, the "git checkout -b branch-name" is just shorthand for convenience. I've been learning git over a mere 2 months (I came from svn), I'm finding its UI to be very pleasant. As someone else said, that index/staging/cached situation is bad, though.

pfranz 12y ago
"If you want to revert/reset a file, why don't you just use the reset command? That seems like a more direct way than using checkout." Because that's what git tell you to do when you run "git status" # (use "git checkout -- <file>..." to discard changes in working directory)
gecko 12y ago
Interesting you should mention "git reset", because, depending on the options you give it, it either: * reverts one file * reverts all files * removes changes from the index, but doesn't otherwise change anything at all * moves your branch, without changing any files * moves your branch and changes all files This rather makes my point. "git checkout -b", meanwhile, is not a shorthand for "git branch something", but rather "git branch --track something origin/something", unless there is no "origin/something", in which case you are again correct.

russelldavis 12y ago

The branch equivalent is `git checkout foo --`. I wrote a simple shell script[1] that makes that the default, requiring you to do `-- <file>` for files, so there's never a possibility of ambiguity. [1] https://gist.github.com/russelldavis/e5173ce1269fae67baaf https://gist.github.com/russelldavis/e5173ce1269fae67baaf

sampo 12y ago

> "the plan was for what is now called Git to be the underlying implementation of a higher-level UI" Some time around year 1960, the plan was to develop a language with syntax ("M-expressions") on top of the Lisp S-expressions. We are still waiting, I guess. http://www-formal.stanford.edu/jmc/history/lisp/node3.html http://www-formal.stanford.edu/jmc/history/lisp/node3.html

qrohlf 12y ago

Relevant: http://stevelosh.com/blog/2013/04/git-koans/ http://stevelosh.com/blog/2013/04/git-koans/

rkwz 12y ago

> Way back when Git was first created, the plan was for what is now called Git to be the underlying implementation of a higher-level UI. Has anyone attempted to actually implement this? Building a 'VCS' on top of git but with a simple 'UI'?

skrause 12y ago
http://en.wikipedia.org/wiki/Cogito_(software) http://en.wikipedia.org/wiki/Cogito_(software)
gammarator 12y ago
EasyGit, and others: https://people.gnome.org/~newren/eg/ https://people.gnome.org/~newren/eg/