[RFD] consider "git" wrapper semi-Porcelain

[Junio C Hamano <junkio@cox.net>]

Currently "git" wrapper suggests both low-level git-* commands
and git-*-script commands as alternatives.  Earlier I stated
that git-*-script commands, like it or not, form a perfectly
good set of barebone Porcelain, as opposed to all the other
commands that do not end with "script" are low-level Plumbing.
After reviewing the current set of commands and scripts again, I
still think this view holds true [*1*, *2*].

I would propose the following, preferably before we go 1.0:

 (1) Do not suggest low-level Plumbing commands to "git" wrapper
     users, and do not call anything but git-*-script from "git"
     wrapper.  Once *-script Porcelain matures, hopefully
     everyday workflow would not require access to low-level
     Plumbing and can be done with git-*-script Porcelain.  When
     people know the GIT way, they can also work it around
     things that git-*-script Porcelain does not support well by
     writing their own git-*-script in terms of Plumbing-ish
     git-* commands, and if it is good enough for public
     consumption, propose it for inclusion upstream.

 (2) Make an alias git-whatchanged-script that just "exec"s
     git-whatchanged, to make things consistent.

 (3) Rename some git-*-script that are misnamed in the sense
     that they are not useful standalone scripts but more of
     Plumbing that happen to be written in shell [*3*].  I do
     not particularly like this proposal, because this breaks
     existing scripts.  However, if we go this route for
     consistency, I would further suggest renaming Porcelain-ish
     things git-*-cmd or something, call and suggest them from
     "git" wrapper, regardless of which language they are
     written in [*4*].


[Footnotes]

*1* One exception is git-whatchanged.

*2* That is the reason I did not name git-cherry
"git-cherry-script".  It is not useful standalone but meant to
be useful in scripting environment.

*3* git-apply-patch-script (my fault) and
git-merge-one-file-script fall into this category.

*4* Current naming and the proposal (1) above have a problem in
that they muddy the definition of what is "script": the name
"script" were originally used because they were written in
shell, and all of the Porcelain-ish things happen to be
"script".  Writing Porcelain-ish things in shell should not be a
requirement.