Re: EasyGit Integration

[Sam Vilain <sam@vilain.net>]

Junio C Hamano wrote:
>> 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.
>   

Ok. Off-hand I can't remember why we excluded "git revert -- path" as
workable. Whatever that reason was led to the group of core developers
coming up with these "clearly" "_inferior_" names.

That could solve the problem, switching behaviour on the type of
argument passed rather than including it in the command name. I think
that was my preferred option at the time, too. Perhaps some other
attendees can recall more clearly...

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

Yes, I agree that if the old behaviour is not being deprecated it
probably shouldn't be replicated as well.

In fact that may have been the argument for excluding 'git revert
filename' - because you can already do that with 'git checkout HEAD --
filename'; but perhaps in this case it is acceptable, because the
'checkout' command can also check out from other revisions, but revert
can't.

Sam.