Re: EasyGit Integration

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 10, 2009, 02:18 UTC
Message-ID: <7vws7khlvj.fsf@alter.siamese.dyndns.org>
In-Reply-To: <4A2F0B8A.9010203@vilain.net>

Sam Vilain <sam@vilain.net> writes:

> We talked about this much at GitTogether '08. It's true that for
> 'reverting' a change in the past, that is the right thing to do. However
> I don't think there is a first principles case that this is always what
> people mean by 'revert'....

Sorry; what you think people mean by 'revert' does not matter at this point, unless you are building a brand-new system from scratch.

> I think as long as there is a deprecation cycle, and that users can
> select the old behaviour (either via an alias or a config option), then
> we shouldn't upset many long-time users of revert. Do you agree?

I actually don't.

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.

By the way, I have a bigger issue.

Some changes in "eg" may port well as a new command to git-core, and some change (like this "revert" thing that has different semantics and breaks established workflow) will never be in git-core. People may think that it would not cause many problems if we picked only the non-conflicting bits, but I actually have some reservations about that.

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

 (1) old timers won't use "revert-commit" and "revert-file" at all but use
     "revert" and "checkout -- path"; while

 (2) new people will behave the other way; and

 (3) the documentation will list all of commands from these two disjoint
    sets under "git".

When a "eg" minded person teaches git, the students may have to be told to ignore "revert" and "checkout -- path", because there are other ways to do the same thing in the lingo they are being taught, which is a subset of git commands. The manual pages will be littered with descriptions like "this command, when used this way, is synonymous to using that other command with this option", leaving the reader wondering why there are so many ways to do the same thing.

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.

If new and useful features (e.g. "creating a remote repository over SSH in one shot") are supported by another Porcelain (e.g. "eg") they may be worth porting over to git-core, in order to make git-core more usable. There is a precedent for that kind of side port (e.g. "filter-branch" that came from Cogito).

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.

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.