From: Junio C Hamano <junkio@cox.net>
Date: Sun, 20 Aug 2006 22:17:15 GMT
Subject: Re: Unresolved issues #3
Message-ID: <7vy7tjxdas.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <1155923876.10054.205.camel@cashmere.sps.mot.com>

Jon Loeliger <jdl@freescale.com> writes:

> I have another:
>
> git-daemon virtualization so that consistent HTTP and
> native git protocols can appear to use consistent URLs
> even in the face of HTTP configurations aliasing them
> to somewhere else on the filesystem and for multiple
> virtually hosted domain names.

Good point.

Here are a handful others I have about git-daemon:

 * Possibly add --strict-symlink option we discussed a long time
   ago that prevents symbolic links inside the named whitelisted
   directory hierarchies to step outside.

   Nobody actually jumped up-and-down asking for it since we
   initially discussed this, so we may not need it after all.

 * The whitelist directories need to be specified with full path
   even when --base-path is used, which somewhat felt wrong.  I
   do not have strong feeling about this anymore, though.

 * Extend $GIT_DIR/git-daemon-export-ok mechanism and have it
   read from $GIT_DIR/config.

 * Also extend the same in a way similar to the discussion we
   had between Aneesh, me and Jakub to control 'blame' and
   'snapshot' in gitweb.  I.e. allow the site-wide configuration
   to specify which services are enabled by default and which
   services can be overridden per repository, and allow per
   repository configuration to specify what's enabled and what's
   not.

 * Add git-upload-tar as a potential program that can be
   executed from git-daemon.

If we are to do the last three items, my thinking is to do
something like this:

  * The config file can have:

       daemon.upload-pack = yes | no
       daemon.upload-tar = yes | no

      to enable or disable the services individually.

  * $GIT_DIR/git-daemon-export-ok is kept as a backward
    compatibility measure; it means upload-pack is enabled.

If we were to allow git-upload-tar from git-daemon:

 * Fix protocol exchange between git-upload-tar and git-tar-tree
   so that the downloader can name the <tree-ish> symbolically
   like this:

	git tar-tree --remote=git://git.kernel.org/pub/scm/git/git next

   Currently the downloader has to get the value of "next" at
   the remote server out-of-band and give an explicit object
   name.