Re: EasyGit Integration

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: Jun 11, 2009, 00:18 UTC
Message-ID: <94a0d4530906101718r4bd6b127y40e6e524afc5f38f@mail.gmail.com>
In-Reply-To: <alpine.LFD.2.01.0906101555590.6847@localhost.localdomain>

On Thu, Jun 11, 2009 at 2:04 AM, Linus Torvalds<torvalds@linux-foundation.org> wrote:

Show 35 quoted lines

>
>
> On Thu, 11 Jun 2009, Felipe Contreras wrote:
>
>> On Wed, Jun 10, 2009 at 7:03 AM, Linus
>> Torvalds<torvalds@linux-foundation.org> wrote:
>> >
>> >
>> > On Tue, 9 Jun 2009, Theodore Tso wrote:
>> >>
>> >> 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.

Show 14 quoted lines

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

Show 8 quoted lines

> 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