do people use the 'git' command?

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?

On Fri, Jun 10, 2005 at 12:53:32PM -0600, Sebastian Kuzminsky wrote:

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

Kay

Kay Sievers <kay.sievers@suse.de> wrote:

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

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

jon.

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" ;-).

Junio C Hamano <junkio@cox.net> wrote:

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(-)

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.

I meant to say:

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

jon.

bollocks :-)!

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 <junkio@cox.net> wrote:

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.

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?

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.

On Sat, Jun 11, 2005 at 12:02:20AM -0700, Junio C Hamano wrote:

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.

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.

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

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.

On 6/11/05, Russ Allbery <rra@stanford.edu> wrote:

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.

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.

Junio C Hamano <junkio@cox.net> writes:

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.