Sam Vilain <sam@xxxxxxxxxx> writes:
> We talked about this much at GitTogether '08. It's true that for
> 'reverting' a change in the past, that is the right thing to do. However
> I don't think there is a first principles case that this is always what
> people mean by 'revert'....
Sorry; what you think people mean by 'revert' does not matter at this
point, unless you are building a brand-new system from scratch.
> 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.
By the way, I have a bigger issue.
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.
If "eg" (I do not have _anything_ against it; the discussion applies to
other Porcelains as well) were kept independent _and_ offered complete set
of features that users need without resorting to git-core, on the other
hand, the students do not have to know about "revert", and the manuals
they need to consult will not have to talk about "if you are using
git-core, this is done differently in this way". The learning curve will
get a lot smoother for new people.
If new and useful features (e.g. "creating a remote repository over SSH in
one shot") are supported by another Porcelain (e.g. "eg") they may be
worth porting over to git-core, in order to make git-core more usable.
There is a precedent for that kind of side port (e.g. "filter-branch" that
came from Cogito).
But aliases for doing essentially the same thing in slightly different
syntax? I'd rather not to see them called "git foo". In the end, I think
it will harm the users, both new and old.
If you go back to the list archive, you will find me suggesting a new set
of commands with "gh" prefix, back in 1.3.X days, I think.
I was not joking. The reasoning was exactly the same, and it remains so.
--
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