Re: EasyGit Integration
- From
Jakub Narebski <jnareb@gmail.com>
- Date
- Jun 10, 2009, 06:43 UTC
- Message-ID
- <m3hbyo4mis.fsf@localhost.localdomain>
- In-Reply-To
- <4A2F1FD0.8060303@vilain.net>
Sam Vilain <sam@vilain.net> writes:
Show 18 quoted lines
> 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