Re: EasyGit Integration

From: Scott Chacon <schacon@gmail.com>
Date: Jun 10, 2009, 16:48 UTC
Message-ID: <d411cc4a0906100948qd499996o8d092686a1643167@mail.gmail.com>
In-Reply-To: <7vws7khlvj.fsf@alter.siamese.dyndns.org>

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.

Show 7 quoted lines

> 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