Re: EasyGit Integration

[Scott Chacon <schacon@gmail.com>]

Hey,

On Tue, Jun 9, 2009 at 7:18 PM, Junio C Hamano<gitster@pobox.com> wrote:
> I do not think introducing "git revert-file" (or "git revert -- path") is
> a problem at all.  But "git revert $commit" has been and is an integral
> part of the established git workflow, and I do not see a point in changing
> it to mean something else, with any deprecation period.

I would vote for simply adding 'revert-file' rather than overloading
another command with two completely different actions.

> It will bloat the total number of subcommands you can give git, with the
> end result being

It just seems that this is sort of a paving the cow paths practice - I
see a lot of people creating aliases for 'unstage' and 'revert-file'
and 'uncommit' and things that are relatively common but difficult to
remember how to do because they have very obscure syntaxes
(syntaxen?).

Worrying about subcommand bloat seems a tad silly at this point given
that there are over 150 valid verbs now, right?  If existing commands
do categorically different things depending on input values, doesn't
it make sense to simply have different verbs exist for each separate
action?  I mean, worrying about the usability issue of having too many
commands but not thinking that making users learn 'git reset HEAD
path' is an issue seems really strange to me.

> If "eg" (I do not have _anything_ against it; the discussion applies to
> other Porcelains as well) were kept independent _and_ offered complete set
> of features that users need without resorting to git-core, on the other
> hand, the students do not have to know about "revert", and the manuals
> they need to consult will not have to talk about "if you are using
> git-core, this is done differently in this way".  The learning curve will
> get a lot smoother for new people.

I think I understand the argument here, but I really, really don't
want to suggest to people to install Git and then install a separate
porcelain, and then have them spend time learning a command set that
is completely absent from other machines that have Git installed.  I
realize this is also an issue with adding new commands (in that they
would be absent from machines with older Git installed) but that issue
fades away after a few years, where the previous does not - in fact,
it becomes a far more difficult problem.

If it's not installed with 'apt-get git-core' or what have you, then I
(and I assume others) are never going to waste everyones time teaching
them a niche tool they will never find elsewhere.

> But aliases for doing essentially the same thing in slightly different
> syntax?  I'd rather not to see them called "git foo".  In the end, I think
> it will harm the users, both new and old.

It would be one thing if I were suggesting that 'git revert' be
changed to 'git regress' or something - it's not a simple naming
issue.  It's more that things like "git reset HEAD <file>..." to
unstage simply makes no sense unless you have a pretty technical
understanding of reset, the index and HEAD - none of which a beginning
user should need to learn right off the bat.  Unstaging files _is_,
however, something that a brand new user will need to do right off the
bat.  The only paths left to them, then, are either learning the
technical details of the index and 'reset' to understand why that
command makes sense, or to simply learn the command by rote - which is
nearly always what ends up happening, since it's incredibly difficult
to learn the index well.  Hell, I've been using Git pretty extensively
for years now and I still have a hard time remembering exactly what
'reset' will do in different circumstances.

Easy things that users have to do a lot should be easy, is all.
Besides just being nice for users, it would probably save a lot of
grief for you guys with people asking and complaining about these
things on this list and the IRC channel.

> If you go back to the list archive, you will find me suggesting a new set
> of commands with "gh" prefix, back in 1.3.X days, I think.
> I was not joking.  The reasoning was exactly the same, and it remains so.

Again, having to explain to people "most of the time you use gh for
all this stuff, but occasionally you use 'git'" or vice-versa is just
confusing and error prone.   Introducing some command denormalization
for the sake of getting new users on their feet with less friction
seems less painful both for the developers and experts having to help
said users and for the users themselves.

I wasn't suggesting a core rewrite, I just thought that hitting some
of this low hanging fruit - again, paving the cow paths as it were -
might be relatively painless and save everyone a lot of time.

Scott