Re: EasyGit Integration

Junio C Hamano wrote:

quoted

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.