5 ms·

Git's GUI is full of horrible features, whcih are almost impossible to learn. Why does 'git checkout' do double-duty, of checking out a clean copy of a file/di

Git's GUI is full of horrible features, whcih are almost impossible to learn. Why does 'git checkout' do double-duty, of checking out a clean copy of a file/directory in the current branch, and checking out a different branch? How does that fit into "learning the mental model of git" If I have a directory called "master", and a branch called "master", what does "git checkout master" do? How do I force git to do the other one? (I know this, but I shouldn't have to)

derefr 10y ago
I'm not disagreeing with you. I'm more saying that in a world where people "met Git where it lives"—learned the internal model Git is based on—the Git GUI with its misfeatures wouldn't exist. Picture factoring Git out into 1. a library that manipulates content-addressible manifest-tree pool directories; and 2. a GUI that consumes that library. Now, throw away the second thing. The fact that even #1 hasn't happened already—and that there's no demand for it to happen—is a testament to just how obscure Git makes what it does. Git's internals could be the next LevelDB; they're that much of a swiss-army knife. But instead, we just have git(1), in all its ugliness.
saurik 10y ago
Actually, git checkout makes perfect sense if you have the git mental model: git checkout makes your index and working copy equivalent to something in the repository. By default, that thing is HEAD, but it can be some other branch if you desire. Checking out a clean copy of a file from the current branch is just a special case of checking out clean copies of files from some other branch.
- marcandre 10y ago
  `git checkout my_branch` does something else that is quite different: it changes the current branch! Also, `git checkout my_branch` is very different from `git checkout my_branch -- .` I strongly dislike the double duty of `checkout`. It's made worse by the fact that `git checkout my_branch` will never lose uncommitted changes, while as `git checkout files` will.
  - saurik 10y ago
    It changes the current branch as it brings in clean files from that branch. Bringing in specific clean files from another branch is a special case of bringing in all clean files from another branch. I look at the current HEAD pointer being changed as a side effect when used without file arguments as it simply changing another file: the HEAD symlink. Think of the HEAD symlink as existing above your target commit (and it kind of does) and it makes a lot of sense. But regardless: the goal of git checkout without file arguments is something you have to have, and if you then ask yourself what tool should implement just the tiny bit of functionality of reverting changes adding a separate command for that seems awkward when that is 99% of what git checkout is doing.
    - CJefferson 10y ago
      I feel you are over defending git. There is effectively two commands here, why not just give them different names? The man page starts "switch branches or restore working tree files", which sounds like ramming two things together. Then the manual has to have a special section on how to disambiguate the two uses (files and branches). It would be less work to have an unambiguous command. Perhaps, at least, make the -- separating files and branches mandatory (so you have to start -- always with files)

derefr 10y ago

I'm not disagreeing with you. I'm more saying that in a world where people "met Git where it lives"—learned the internal model Git is based on—the Git GUI with its misfeatures wouldn't exist. Picture factoring Git out into 1. a library that manipulates content-addressible manifest-tree pool directories; and 2. a GUI that consumes that library. Now, throw away the second thing. The fact that even #1 hasn't happened already—and that there's no demand for it to happen—is a testament to just how obscure Git makes what it does. Git's internals could be the next LevelDB; they're that much of a swiss-army knife. But instead, we just have git(1), in all its ugliness.

saurik 10y ago

Actually, git checkout makes perfect sense if you have the git mental model: git checkout makes your index and working copy equivalent to something in the repository. By default, that thing is HEAD, but it can be some other branch if you desire. Checking out a clean copy of a file from the current branch is just a special case of checking out clean copies of files from some other branch.

marcandre 10y ago
`git checkout my_branch` does something else that is quite different: it changes the current branch! Also, `git checkout my_branch` is very different from `git checkout my_branch -- .` I strongly dislike the double duty of `checkout`. It's made worse by the fact that `git checkout my_branch` will never lose uncommitted changes, while as `git checkout files` will.
- saurik 10y ago
  It changes the current branch as it brings in clean files from that branch. Bringing in specific clean files from another branch is a special case of bringing in all clean files from another branch. I look at the current HEAD pointer being changed as a side effect when used without file arguments as it simply changing another file: the HEAD symlink. Think of the HEAD symlink as existing above your target commit (and it kind of does) and it makes a lot of sense. But regardless: the goal of git checkout without file arguments is something you have to have, and if you then ask yourself what tool should implement just the tiny bit of functionality of reverting changes adding a separate command for that seems awkward when that is 99% of what git checkout is doing.
  - CJefferson 10y ago
    I feel you are over defending git. There is effectively two commands here, why not just give them different names? The man page starts "switch branches or restore working tree files", which sounds like ramming two things together. Then the manual has to have a special section on how to disambiguate the two uses (files and branches). It would be less work to have an unambiguous command. Perhaps, at least, make the -- separating files and branches mandatory (so you have to start -- always with files)