From: Jakub Narebski <jnareb@gmail.com>
Date: Wed, 10 Jun 2009 06:43:14 GMT
Subject: Re: EasyGit Integration
Message-ID: <m3hbyo4mis.fsf@localhost.localdomain>
In-Reply-To: <4A2F1FD0.8060303@vilain.net>

Sam Vilain <sam@vilain.net> writes:
> 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.

"git revert -- path" is perhaps not unambiguous (but for the fact
whether it reverts from index, or from HEAD), but "git revert <rev> -- path"
can be understood as "git cherry-pick -R <rev> -- path" i.e. reverting
changes to given file or files in a commit.

And we have "git reset -- file", don't we.
-- 
Jakub Narebski
Poland
ShadeHawk on #git