On Tue, 24 Oct 2006, Lachlan Patrick wrote:
>
> Can I ask the git folks what Sean meant in the above about a 'command'.
> Are you talking about shell scripts? Is 'git' the only program you need?
Historically, "git" was _only_ a wrapper program. When you did
git log
it just executed the real program called "git-log", which was often a
shell-script. That was just so that things could easily be extended, and
you could use shell-script for simple one-liner things, and native C for
more "core" stuff.
For example, "git log" used to be a one-line shell-script that just did
git-rev-list --pretty HEAD | LESS=-S ${PAGER:-less}
but it ended up being a lot more capable, and eventually just rewritten
as an internal command..
These days, most of the simple things like "git log" are all built into
the "git" program, although for anything not built in, it still acts as
just a wrapper, which allows not only random functionality to still be
written in shell (or sometimes perl), but also ends up being the simplest
possible plug-in mechanism: you can define your own commands by just
writing a shell-script thing, calling it "git-mycommand", installing it in
the proper place, and it ends up being accessible as "git mycommand".
That allows for easy prototyping in your language of choice.
> AFAIK, 'bzr' is the sole program in Bazaar, and everything is done with
> command line options to bzr. Is that true of git? To what extent is git
> tied to a [programmable] shell? I've heard someone say there's no
> Windows version of git for some reason, can someone elaborate?
Almost all of "core" git is pure C, which unlike something like python or
perl obviously tends to have a fair amount of system issues. That said,
much of it really is fairly portable, so doing the built-in git stuff
should _largely_ work even natively under Windows with some effort.
The problem ends up being that few enough people seem to develop under
Windows, and the cygwin port works better (because it handles a number of
the portability issues and also handles the scripts that are still shell).
Those two issues seem to mean that not a lot of effort has been put into
aiming for a native windows binary (or into moving away from shell
scripts).
Most of the shell scripts really are fairly simple. So if somebody
_really_ wanted to, it would probably not be hard to spend some effort to
either just write them as C and turn them into built-ins, or porting them
to some other scripting language.
Of course, most Windows users don't seem to really want a command line
interface at all. IDE integration would appear to be more interesting to
some people.
Linus
-
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