Re: EasyGit Integration

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: Jun 11, 2009, 00:30 UTC
Message-ID: <94a0d4530906101730p22053cbbl347eddd31b347c3c@mail.gmail.com>
In-Reply-To: <m38wjz4odq.fsf@localhost.localdomain>

On Thu, Jun 11, 2009 at 3:15 AM, Jakub Narebski<jnareb@gmail.com> wrote:

Show 27 quoted lines

> Scott Chacon <schacon@gmail.com> writes:
>> On Wed, Jun 10, 2009 at 4:04 PM, Linus
>> Torvalds<torvalds@linux-foundation.org> 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.

'git reset' also gets something out of the repository and into the working area, that's not reason enough to put them under the same 'checkout' command, is it?

Show 13 quoted lines

> [...]
>> 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...

Backwards compatibility must be broken at some point or another, otherwise people will start to create their own aliases, alternative UI's and even forks. Sure, it must be done carefully and planned in advance, that's why it's a good idea to keep a list of things to change in the next interface break.

-- 
Felipe Contreras