Sam Vilain <sam@xxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html