Re: VCS comparison table

[Shawn Pearce <spearce@spearce.org>]

Lachlan Patrick <loki@research.canon.com.au> 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?

'git' is actually two things:

  1) Its a wrapper command which executes 'git-foo' if you call it
     with 'foo' as its first parameter.  It searches for 'git-foo'
     in the GIT_EXEC_PATH environment variable, which has a default
     set at compile time, usually to the directory you are going to
     install Git into.

  2) Its most of the core Git plumbing.  There are currently around 48
     'builtin' commands.  These are things which 'git' knows how to do
     without executing another program.  If you look at the installation
     these 48 builtin commands are just hardlinks back to 'git'.  For
     example 'git-update-index' is really just a hardlink back to 'git'
     and 'git' knows to perform the update index logic when its called
     as either 'git-update-index' or as 'git update-index'.

We're moving more towards #2, but there are still a large number
of commands which fall into #1.
 
> AFAIK, 'bzr' is the sole program in Bazaar, and everything is done with
> command line options to bzr. Is that true of git?

No.  In Git at least half of the things Git can do are not builtin to
'git' and thus require exec()'ing an external program (e.g. git-fetch).
However these often appear as though they are command line options to
'git' as 'git fetch' just means exec 'git-fetch' (by #1 above).

On the other hand there are a wide range of tools which are more or
less the same thing, just with different options applied to them.
All of the diff programs, log, whatchanged, show - these are all
just variations on a theme.  Their individual implementations are
very tiny as they all use the same library code.

> To what extent is git
> tied to a [programmable] shell?

Git is still very much tied to a shell.  For example 'git commit'
is really the shell script 'git-commit'.  This is a rather long
shell script and it does a lot of things for the user; not having
it would make Git useless to for most people.  It also has not been
rewritten in C.  There is a roadmap however to convert it to C to
help remove the programmable shell requirement and people have been
slowly performing the (rather tedious) conversion work.

> I've heard someone say there's no
> Windows version of git for some reason, can someone elaborate?

Git runs on Cygwin.  But there's no native Win32 (without Cygwin)
version of Git because:

 - Git uses POSIX APIs and expects POSIX behavior from the OS its
   running on.  Without a compatability layer to make Windows act
   like UNIX Git won't run.  Cygwin happens to be a really good
   compatability layer.

 - Git requires a Bourne shell for many of its important tools,
   such as 'git commit'.  Windows lacks such a program, at least
   out of the box, but its in Cygwin.

 - Git relies on a helper program called 'merge' to perform three
   way file merges.  This tool may or may not be ported to native
   Win32 (I don't know) but it is in Cygwin.

 - Git requires some libraries for certain features, such as libexpat
   or libcurl.  I don't know if these are available for native Win32
   but they are available on Cygwin.

 - Windows isn't the primary target platform for many of the Git
   contributors.  Some consider the fact that it even runs there
   at all a minor miracle, and that's only possible due to the hard
   work the Cygwin folks have done.

 - ... I'm sure there's other reasons ...

-- 
Shawn.