As one of the people who helps maintain git packages in pkgsrc, my
initial reaction is negative to adding a ruby dependency.  There are
several not-entirely-related reasons:

git is a core tool that people use on almost the smallest of boxes,
perhaps even replacing rcs for managing local config files.  On such
machines, even perl may be large, but a second scripting language seems
excessive.  On a NetBSD 6 i386 system, the size of the ruby193-base
binary package (as installed) is 25 MB (vs 15 MB for the git base
package, which lacks gitk and docs).  (Presently, the git base package
defaults to requiring python and installing the git_remote_helpers, but
I think that's a bug.)  perl is 54 MB.

I am unclear on how mature/stable ruby is.  perl has a good track record
over the last many years.  In particular, no one in pkgsrc has felt the
need to support multiple concurrent versions of perl.  But there
presently exists both 1.8 and 1.9 in pkgsrc (and there are multiple
python verions).  So given how critical git is on many systems, I'd ask
if the ruby requirement is for a stable vs old vs bleeding-edge version,
and how that is expected to function over the next 5 years.  (With perl,
the answer seems to be "any half-way modern version of 5.x is fine, from
unreasonably old to the latest release".)  By stable, I don't mean that
a particular ruby release works well.  I mean the experience of having
code that depends on ruby over many years, and whether one can just use
whatever ruby happens to be there, or whether it's effort to manage
having an acceptable version.

From a packaging viewpoint, dependencies are costly, because they force
build and installation of them before the package can be built.  In a
source-centric packaging environment (where it's normal to build, rather
than only having pre-built packages), the question is if the git package
needs ruby, which is a different question than whether something in git
which may be optional needs ruby.  So if ruby, or something else, is
needed for optional components, it would be really nice if the build
system were such that it was simple (via arguments to configure,
selecting subdirs, or something functionally similar) to build the main
part, and then the ruby part as a separate build.  Then, it would be
pretty easy to have git-ruby package that has the ruby parts.  But if
the ruby part isn't considered optional, that won't work.  (Note that
the usual GNU/Linux approach of split binary packages doesn't really
address this, because as I understand it you need the union of the
dependencies installed to build once, and then tar up the resulting bits
separately.  So that fixes the problem for people that install binaries,
but doesn't help building from source.)

tcl/tk is another dependency, but it seems limited to gitk.  pkgsrc has
a separate scmgit-gitk package, which is relatively easy to maintain
because it just involves selecting subdirs to build.  So that's an
example of a good way to do it, from the source-based packaging
viewpoint.

Finally, I realize that most people on this list will build git directly
From sources.  While that of course has to be smooth, I think great
weight should be given to how packaging systems use releases and how
that impacts packaging effort and the eventual user experience.  I would
guess that over 99% of git users are running binaries built from a
packaging system.