Hey,
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'. If you provide both
a branch and a filename, what happens? It still means 'extract
content'. 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'.
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_'.
>
> Humans are generally _very_ good at seeing the same word in two different
> contexts, and not being confused at all. There is no confusion when I talk
> about SCM's in the context of git, even though "SCM" could also mean a
> Sceme interpreter, or "Saskatchewan College of Midwives".
>
> In fact, it is often *much* better to accept context-awareness, than to
> try too hard to be "uniquely identifying" even without context.
This may be generally true for conversational language, but that
doesn't really cleanly apply here. If your vocabulary is only like 15
words (common porcelain commands), why would one of them be ambiguous
outside of context? Even given proper context, we're still being
arbitrary about how that command is interpreted - what if they wanted
to 'extract content' of all the files from another branch? Having
learned that 'git checkout <file>' extracts content of that file and
'git checkout <branch> <file>' extracts the contents of that file from
that branch, why wouldn't one assume that 'git checkout <branch>'
extracts the content of all the files in that branch? Wouldn't that
make more sense than arbitrarily doing something completely unrelated
('switching active branch')?
I'm not just arguing for arguments sake - I'm relaying from
individuals I'm trying to teach this to that they find it confusing.
This is not a theoretical argument, it is real world user feedback. I
probably struggled with things like this a bit at first and then
learned the idiosyncrasies of the tool and just accepted it like most
of the rest of us have - but many people honestly get confused and
frustrated by it. I see many of us helping people on IRC and whatnot
with this type of thing all the time.
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)?
Scott
--
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