do people use the 'git' command?

do people use the 'git' command?

[Sebastian Kuzminsky]

What good is the 'git' command?  It's a shortcut to run the
"git-$FUNCTION-script" programs, but it doesnt do the "git-$FUNCTION"
programs.  It just doesnt seem worth its inode, to me.  And it doesnt seem
worth the pain to distribution maintainers (like me) to avoid the naming
conflict with GNU Interactive Tools' /usr/bin/git.


Can we drop the "git" program?


diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -42,7 +42,7 @@ CC?=gcc
 AR?=ar
 INSTALL?=install
 
-SCRIPTS=git git-apply-patch-script git-merge-one-file-script git-prune-script \
+SCRIPTS=git-apply-patch-script git-merge-one-file-script git-prune-script \
 	git-pull-script git-tag-script git-resolve-script git-whatchanged \
 	git-deltafy-script git-fetch-script git-status-script git-commit-script \
 	git-log-script git-shortlog git-cvsimport-script
diff --git a/git b/git
deleted file mode 100755
--- a/git
+++ /dev/null
@@ -1,4 +0,0 @@
-#!/bin/sh
-cmd="git-$1-script"
-shift
-exec $cmd "$@"


-- 
Sebastian Kuzminsky

Re: do people use the 'git' command?

[Kay Sievers]

On Fri, Jun 10, 2005 at 12:53:32PM -0600, Sebastian Kuzminsky wrote:
> What good is the 'git' command?  It's a shortcut to run the
> "git-$FUNCTION-script" programs, but it doesnt do the "git-$FUNCTION"
> programs.  It just doesnt seem worth its inode, to me.  And it doesnt seem
> worth the pain to distribution maintainers (like me) to avoid the naming
> conflict with GNU Interactive Tools' /usr/bin/git.

Well, drop the GNU Interactive Tools instead. We've removed it from the
SuSE packages and have a "real" git package now. :)

Kay

Re: do people use the 'git' command?

[Sebastian Kuzminsky]

Kay Sievers <kay.sievers@suse.de> wrote:
> On Fri, Jun 10, 2005 at 12:53:32PM -0600, Sebastian Kuzminsky wrote:
> > What good is the 'git' command?  It's a shortcut to run the
> > "git-$FUNCTION-script" programs, but it doesnt do the "git-$FUNCTION"
> > programs.  It just doesnt seem worth its inode, to me.  And it doesnt seem
> > worth the pain to distribution maintainers (like me) to avoid the naming
> > conflict with GNU Interactive Tools' /usr/bin/git.
> 
> Well, drop the GNU Interactive Tools instead. We've removed it from the
> SuSE packages and have a "real" git package now. :)

That sounds nice!  If only it weren't for all those pesky users...


-- 
Sebastian Kuzminsky

Re: do people use the 'git' command?

[Jon Seymour]

Not in a program, but it does make some things slightly easier to type.

jon.

Re: do people use the 'git' command?

[Junio C Hamano]

>>>>> "SK" == Sebastian Kuzminsky <seb@highlab.com> writes:

SK> Can we drop the "git" program?

No chance, especially with a patch that is not accompanied with
necessary changes to Documentation/tutorial.txt that already
tells the user to type "git commit" and "git log" ;-).

Re: do people use the 'git' command?

[Sebastian Kuzminsky]

Junio C Hamano <junkio@cox.net> wrote:
> >>>>> "SK" == Sebastian Kuzminsky <seb@highlab.com> writes:
> 
> SK> Can we drop the "git" program?
> 
> No chance, especially with a patch that is not accompanied with
> necessary changes to Documentation/tutorial.txt that already
> tells the user to type "git commit" and "git log" ;-).

Of course, you're right.  How about this?  Against Cogito but applies
cleanly to Linus' git:


 b/Documentation/cvs-migration.txt |    4 ++--
 b/Documentation/tutorial.txt      |    6 +++---
 b/Makefile                        |    2 +-
 git                               |    4 ----
 4 files changed, 6 insertions(+), 10 deletions(-)


diff --git a/Documentation/cvs-migration.txt b/Documentation/cvs-migration.txt
--- a/Documentation/cvs-migration.txt
+++ b/Documentation/cvs-migration.txt
@@ -63,7 +63,7 @@
 any more familiar with it, but make sure it is in your path. After that,
 the magic command line is
 
-	git cvsimport <cvsroot> <module>
+	git-cvsimport-script <cvsroot> <module>
 
 which will do exactly what you'd think it does: it will create a git
 archive of the named CVS module. The new archive will be created in a
@@ -90,7 +90,7 @@
 
 So, something has gone wrong, and you don't know whom to blame, and
 you're an ex-CVS user and used to do "cvs annotate" to see who caused
-the breakage. You're looking for the "git annotate", and it's just
+the breakage. You're looking for the "git-annotate", and it's just
 claiming not to find such a script. You're annoyed.
 
 Yes, that's right.  Core git doesn't do "annotate", although it's
diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.txt
@@ -362,7 +362,7 @@
 for you, and starts up an editor to let you write your commit message
 yourself, so let's just use that:
 
-	git commit
+	git-commit-script
 
 Write whatever message you want, and all the lines that start with '#'
 will be pruned out, and the rest will be used as the commit message for
@@ -417,7 +417,7 @@
 To see the whole history of our pitiful little git-tutorial project, you
 can do
 
-	git log
+	git-log-script
 
 which shows just the log messages, or if we want to see the log together
 with the associated patches use the more complex (and much more
@@ -465,7 +465,7 @@
    history outside of the project you created.
 
  - if you want to move or duplicate a git archive, you can do so. There
-   is no "git clone" command: if you want to create a copy of your
+   is no "git-clone" command: if you want to create a copy of your
    archive (with all the full history that went along with it), you can
    do so with a regular "cp -a git-tutorial new-git-tutorial".
 
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -42,7 +42,7 @@
 AR?=ar
 INSTALL?=install
 
-SCRIPTS=git git-apply-patch-script git-merge-one-file-script git-prune-script \
+SCRIPTS=git-apply-patch-script git-merge-one-file-script git-prune-script \
 	git-pull-script git-tag-script git-resolve-script git-whatchanged \
 	git-deltafy-script git-fetch-script git-status-script git-commit-script \
 	git-log-script git-shortlog git-cvsimport-script
diff --git a/git b/git
deleted file mode 100755
--- a/git
+++ /dev/null
@@ -1,4 +0,0 @@
-#!/bin/sh
-cmd="git-$1-script"
-shift
-exec $cmd "$@"


-- 
Sebastian Kuzminsky

Re: do people use the 'git' command?

[Jon Seymour]

Sebastian,

What is the justification for removing it?

As it stands, git serves a useful function in that it provides a
single point through which access to all git-*-scripts is channeled,
yet still allows each script to be maintained as a separate entity,
coherent entity.

jon.

Re: do people use the 'git' command?

[Jon Seymour]

I meant to say:
> yet still allows each script to be maintained as a separate,
> coherent entity.
> 

...but then I tend towards in the randomly incoherent.

jon.

Re: do people use the 'git' command?

[Jon Seymour]

> 
> ...but then I tend towards in the randomly incoherent.
> 
> jon.
> 
bollocks :-)!

Re: do people use the 'git' command?

[Junio C Hamano]

>>>>> "JS" == Jon Seymour <jon.seymour@gmail.com> 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.

Re: do people use the 'git' command?

[Jon Seymour]

On 6/11/05, Junio C Hamano <junkio@cox.net> wrote:
> >>>>> "JS" == Jon Seymour <jon.seymour@gmail.com> 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.

Re: do people use the 'git' command?

[Junio C Hamano]

>>>>> "JS" == Jon Seymour <jon.seymour@gmail.com> writes:

JS> Then:

JS>     git update-cache 

JS> would work as expected.

I'd rather teach the user to say git-update-cache once they
learned how git works.

Let's stop and think.  Compare lower level binaries and
git-*-script commands, especially paying attention to the level
of operation of what they do.  Notice the difference?

The git-*-script commands are already more or less Porcelain
themselves, and for that reason alone, they deserve to have
CVS/SVN familiarity wrapper.  They are designed to be usable
even by people who are still not familiar with the GIT way of
doing things, and the purpose of the "git" wrapper is to help
these people try putting their toes in the water.  Once they
understand how these scripts work, they either care about
Plumbing because they want to do something existing Porcelain
layers do not offer (in which case they would write their own
Porcelain extensions using Plumbing commands).  Or with luck,
they may not have to worry about Plumbing at all.

I grant you that what the current "git" wrapper offers is not
Porcelain enough, and to perform anything meaningful you either
need to use Porcelain or bare Plumbing commands yourself.  But
when that day comes, "git update-cache" is not something you
would want to have anyway.  You would rather want to have things
like "git add" and "git remove", which are written in terms of
git-update-cache.

See what I am saying?

Re: do people use the 'git' command?

[Jon Seymour]

> I grant you that what the current "git" wrapper offers is not
> Porcelain enough, and to perform anything meaningful you either
> need to use Porcelain or bare Plumbing commands yourself.  But
> when that day comes, "git update-cache" is not something you
> would want to have anyway.  You would rather want to have things
> like "git add" and "git remove", which are written in terms of
> git-update-cache.
> 
> See what I am saying?

Ok, that's fair enough. It is a sound to expose bits of plumbing to
the porcelain in a very slow and deliberate way as the porcelain is
polished, rather than automatically surfacing plumbing as it gets
created by over-enthusiastic plumbers.

My own learning experience has been exactly the other way around to
the intended use of the git script - I have been learning to use the
core git commands, writing my own wrappers where that is convenient
and adopting those of others only when I completely understand what
they are doing - I have been learning it inside out, I guess.

For example, I only recently discovered what git-commit-script does  [
and I like it - btw - nice behaviour ]!

jon.
-- 
homepage: http://www.zeta.org.au/~jon/
blog: http://orwelliantremors.blogspot.com/

Re: do people use the 'git' command?

[Tommy M. McGuire]

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

Re: do people use the 'git' command?

[Russ Allbery]

Jon Seymour <jon.seymour@gmail.com> writes:

> What is the justification for removing it?

The conflict with the existing GIT package is painful for distributions.
Packagers try hard to avoid any file conflicts between packages, since it
means that both packages cannot be used at the same time, and it turns out
in discussion on the Debian mailing lists that people actually do use GIT.

Managing the conflict between two programs that do completely different
things and are named the same thing is really annoying.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

Re: do people use the 'git' command?

[Jon Seymour]

On 6/11/05, Russ Allbery <rra@stanford.edu> wrote:
> Jon Seymour <jon.seymour@gmail.com> writes:
> 
> > What is the justification for removing it?
> 
> The conflict with the existing GIT package is painful for distributions.
> Packagers try hard to avoid any file conflicts between packages, since it
> means that both packages cannot be used at the same time, and it turns out
> in discussion on the Debian mailing lists that people actually do use GIT.
> 
> Managing the conflict between two programs that do completely different
> things and are named the same thing is really annoying.
> 

Ah, ok...sorry didn't realise there was a naming conflict.

How about renaming:
    "git" to "g.t"
 
And then explaining the idiosyncratic name in git(7).

jon.

Re: do people use the 'git' command?

[Junio C Hamano]

>>>>> "RA" == Russ Allbery <rra@stanford.edu> writes:

RA> ... it turns out in discussion on the Debian mailing lists
RA> that people actually do use GIT.

I thought the Debian way to resolve this kind of naming conflict
was to rename _both_ commands involved.  Sorry if this was a
misconception, but I think I read that somewhere in the
developer's guide.

Re: do people use the 'git' command?

[Russ Allbery]

Junio C Hamano <junkio@cox.net> writes:
>>>>>> "RA" == Russ Allbery <rra@stanford.edu> writes:

> RA> ... it turns out in discussion on the Debian mailing lists
> RA> that people actually do use GIT.

> I thought the Debian way to resolve this kind of naming conflict
> was to rename _both_ commands involved.  Sorry if this was a
> misconception, but I think I read that somewhere in the
> developer's guide.

There are various ways in which you can deal with the problem, but then
you end up making that distribution different possibly than any other and
certainly different than the behavior people get when they build the
package themselves.  Then users ask questions here talking about running
"cogito-git" or the like and developers go "I've never heard of that
program," users try to use recipes off the net and the command isn't
found, etc.

Users of a tool like git are in a better position to figure this sort of
thing out, but it's still rather annoying and frustrating.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>