Scott Chacon <schacon@xxxxxxxxx> writes: > On Wed, Jun 10, 2009 at 4:04 PM, Linus > Torvalds<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > > > IOW, both would be "if you give it a commit, it acts at a commit level", > > and "if you give it pathnames, it acts on a pathname level". > > > > That is totally obvious, and not in the least confusing. They are two > > different things, but at the same time, there is no question about which > > is which. > > > >> In my mind these are 2 completely different commands. > > > > They are two different things, but they both make sense within the > > _context_. > > > > Only earthworms and FOX news have no concept of "in context". So it does > > make sense to say "git checkout filename" (and expect it to check out that > > _filename_ - surprise surprise), and also say "git checkout branch" (and > > expect it to check out that branch - again, big surprise). > > The problem here is that you're using 'check out' in your descriptions > of the expectations to mean two different things. One means 'switch > branches' and the other means 'extract content'. In both cases it means getting something out of repository (checking out) and into working area. > If you provide both > a branch and a filename, what happens? It still means 'extract > content'. If there is a filename, then it is checking out a file or files. If there is no filename, then it is checking out a commit. Checking out commit means switching branch if it is branch name, detaching HEAD if it is not branch name. When you are checking out a file or set of files, you cannot change branch; commit is state of a whole project, not of individual files. > Not everyone assumes that 'checkout' can or should mean > both of these things depending on context. I mean honestly, the > 'context' of 'git checkout branch' and 'git checkout branch file' > doesn't really look that much different, but the command completely > switches semantics from 'switch active branch' to 'extract content'. Note that "git checkout <commit-ish>" was first (well, it was only "git checkout <branch>" then. > It's not that the command assumes some subtle defaults depending on > what arguments you give it - it's that it completely changes the > nature of what it does depending on the arguments. It only makes > sense to us because we specifically learned that it did this, not > because it makes sense intuitively. Hell, _neither_ of these meanings > are what SVN-inbound users are used to, which they map to 'extract > content _from a remote server_'. So perhaps _understanding_ those commands require understanding git model. I don't see how this is a bad thing. You would have to learn it anyway... ;-) [...] > I understand that clarity and ease of use is not really of primary > importance to this project. However, is it not slightly ironic that > the Git project is so obsessed with squeezing 5% or 10% of raw speed > out of each command, yet feels that the onus should be on each user to > study for hours to memorize a bunch of arbitrary idiosyncrasies of the > tool? Can we not obsess a little about flattening the learning curve > 10% as well (possibly at the slight expense of command normalization > or verb bloat)? The problem is bakcward compatibility and the fact that git was not as much as designed, as it has grown. Which is very good solution for getting good feature set, but not so much for an UI... -- Jakub Narebski Poland ShadeHawk on #git -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html