Re: EasyGit Integration

On Thu, Jun 11, 2009 at 3:15 AM, Jakub Narebski[off-list ref] wrote:

Scott Chacon [off-list ref] writes:

quoted

On Wed, Jun 10, 2009 at 4:04 PM, Linus
Torvalds[off-list ref] wrote:

quoted

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.

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

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?

[...]

quoted

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