Re: EasyGit Integration

On Thu, Jun 11, 2009 at 2:04 AM, Linus
Torvalds[off-list ref] wrote:

On Thu, 11 Jun 2009, Felipe Contreras wrote:

quoted

On Wed, Jun 10, 2009 at 7:03 AM, Linus
Torvalds[off-list ref] wrote:

quoted

On Tue, 9 Jun 2009, Theodore Tso wrote:

quoted

My personal opinion is this kind of overloading is actually more
confusing than simply adding a new name, such as "git revert-file".

I'd agree, except I think it actually worked pretty well in "git
checkout".

The alternative was to add yet another command for that, or to teach
people about the internal commands we did have. Adding the capability for
checkout to check out individual files - in addition to commits and
branches - I think worked pretty well.

Why? What makes 'git checkout <commit>' and 'git checkout <commit> --
<path>' similar at all? I would expect 'git checkout <commit>' to be
the same as 'git checkout <commit> -- .'

You don't understand.

"git checkout" would be similar to "git revert", if we did that change.

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.

I'm opposed to 'git revert -- <path>' for many reasons, one of which
is; you might want to grab some files that are in a future commit.
Reverting to the future is weird, unless you did a previous revert
backwards.

I do understand the two different 'git checkout' modes, that's not the
point, my point is the question you didn't answer; what does 'git
checkout <commit>' and 'git checkout -- <path>' have in common?

To me it seems the only thing they have in common is the name.

quoted

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).

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".

Suppose you have a 'debian' branch, and a 'debian' directory, what
does this command do?
git checkout debian

Sure, I'm not an earthworm, so I can guess that command means checkout
the debian branch because it's a much more common action. But git
doesn't know that, you need to do:
git checkout debian --

If I know I want to checkout a branch I would like to do:
git <command to checkout a branch> debian

In fact, it is often *much* better to accept context-awareness, than to
try too hard to be "uniquely identifying" even without context.

Of course, you do want things to also be unambiguous. But that's why we
have things like that "--" thing, when we want to specify pathspecs
explicitly and don't want to accept any kind of ambiguity. Most humans
tend to leave them out, and that "--" thing shows up mostly in git
scripts.

Yeah, unless git finds it ambiguous and the user is forced to learn a
new idiom in order to get rid of the ambiguity.

-- 
Felipe Contreras