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