quoted
quoted
quoted
quoted
"JS" == Jon Seymour [off-list ref] writes:
JS> Sebastian,
JS> What is the justification for removing it?
JS> As it stands, git serves a useful function in that it provides a
JS> single point through which access to all git-*-scripts is channeled,
JS> yet still allows each script to be maintained as a separate entity,
JS> coherent entity.
If I understand him correctly, Sebastian's point was that it
channels only to git-*-scripts without channelling to any of the
git-* binaries.
But the real point of "git" wrapper is merely to present CVS and
SVN refugees the structure they are familiar with: a single
command having a set of subcommands.
It is just an "introductory" thing and there is no compelling
reason to expose the low level core GIT commands. When the
refugees are comfortable with how GIT does things, they will
either use Porcelain and not touch the Plumbing, or they will
learn to use git-* commands themselves. In the former case, not
having access to core GIT commands through "git" wrapper is not
an issue. In the latter case, they will learn to type
git-*-script in no time, and at that point "git" wrapper will be
just a short-hand; again not having access to core GIT commands
through "git" wrapper is not an issue either.
Personally I think removal of "git" script is a bad idea.
On 6/11/05, Junio C Hamano [off-list ref] wrote:
quoted
quoted
quoted
quoted
quoted
"JS" == Jon Seymour [off-list ref] writes:
JS> Sebastian,
JS> What is the justification for removing it?
JS> As it stands, git serves a useful function in that it provides a
JS> single point through which access to all git-*-scripts is channeled,
JS> yet still allows each script to be maintained as a separate entity,
JS> coherent entity.
If I understand him correctly, Sebastian's point was that it
channels only to git-*-scripts without channelling to any of the
git-* binaries.
What about generalizing it a little, so that:
git word
calls:
git-word-script if it exists and is executable in the path
or, if not,
git-word if it exists and is executable in the path.
Then:
git update-cache
would work as expected.
jon.
On Sat, Jun 11, 2005 at 12:02:20AM -0700, Junio C Hamano wrote:
But the real point of "git" wrapper is merely to present CVS and SVN
refugees the structure they are familiar with: a single command having
a set of subcommands.
CVS and SVN refugees (like me :-)) should probably be pointed to
porcelain. Showing them a mixture of relatively unpolished "git
<subcommand>" and "git-*" commands is not likely to impress them with
the simplicity and elegance of the tool. I don't think the surface
structure of "<command> <subcommand>" is an important factor, and
the first time they see a 40-hex-digit number, they'll be headed for the
hills.
Personally I think removal of "git" script is a bad idea.
I'd agree, for the opposite reason: the git script is a decent interface
for power users who don't want to use anything porcelainish. It also
provides a good place to hang custom functionality.
--
Tommy McGuire