From: Nagy Balázs <js@iksz.hu>
Date: Fri, 01 Feb 2008 16:11:10 GMT
Subject: Re: [PATCH] Added sub get_owner_file which checks if there's a file with project owner name
Message-ID: <47A3449E.6070102@iksz.hu>
In-Reply-To: <200802011418.59862.jnareb@gmail.com>

Jakob Narebski wrote:
> Besides I'd rather opt for the other side of spectrum: instead of
> gitweb checking for freshness of a 'cache', regenerate the cache
> or just delete it when you know that contents change: from a script
> adding a repository, from a script renaming or changing description
> or an owner of repository, from a script deleting repository or
> removing it from a list, from a post-update / post-receive hook if
> the cached info includes last change, etc.
>   
[...]

> I was thinking about gitconfig file, but with limited syntax to be
> easily parseable from Perl, like git-cvsserver does, put in $projectroot,
> e.g. $projectroot/gitconfig, which would contain parts of repo config
> relevant to 'projects_list' page.  It would use gitweb.<repo>.<key>
> syntax, where <key> is one of owner, description, and perhaps url.
>
> Or we could put it in gitweb_config.perl file, in the form of parsed
> config hash... well, it should be fairly easy to combine those two
> approaches with current code: use %config hash, and fill it from
> $projectroot/gitconfig if not set.
>
> Of course you would have the usual danger when dealing with data
> duplication, naley that they would get out of sync. And usual danger
> dealing with caches, that the validating needed and other system
> caches would make it perform *worse* than without cache.
Well, I came from ClearCase world, were registry service holds all 
vob/view (repo) stuff.  What if we implement more or less the same 
here?  I mean if you have a lot of public git repos, or at least common 
for a couple of people, we could store all the fundamental data (local 
storage path, share URL) of a group of repos in a single database.  We 
could call them depots.  Moreover, we could use this as the source of 
git clone, God forbid, even remotely (some kind of git config 
depot.url=https://user:pass@git.example.org/depot.cgi/depotname).  I 
could continue but I'm afraid I'll run out of oxygen :)

I'm thinking of something similar:

$ git depot # not the actual usage info, but to show all the parameters
Usage: git depot create [-d | --description=<descr>] <depot> <path>
       git depot remove [-f | --force] <depot>
       git depot modify [-d | --description=<descr> ]
         [-p | --path=<base path>] [-n | --name=<depot>] <depot>
       git depot list
       git depot add [-a | --access=public|private] [-o | --owner=<owner>]
         <depot>[:<name>] <path>
       git depot update [-a | --access=public|private]
         [-o | --owner=<owner>] [-p | --path=<path>] <depot>:<name>
       git depot delete <depot>:<name>
       git depot show [-a | --all] [-l | --long] <depot>
$ git depot list
public /pub/scm "Public repository"
$ git depot show public
public:git /pub/scm/git.git (public, owner: "Junio C Hamano \
<gitster@pobox.com>", description: "The core git plumbing")
public:linux/kernel/torvalds/linux-2.6 \
/pub/scm/linux/kernel/torvalds/linux-2.6.git (owner: \
"Linus Torvalds <torvalds@linux-foundation.org>, description: \
"Linus' Kernel Tree")
$ git depot show --long public:git
Repository: public:git
  Path: /pub/scm/git.git
  Clone URL: git://git.kernel.org/pub/scm/git.git
  Clone URL: http://www.kernel.org/pub/scm/git/git.git
  Access: public
  Owner: Junio C Hamano <gitster@pobox.com>
  Description: The core git plumbing
--
# Access: private means only git depot show -a shows it
$ mkdir ~/git; cd ~/git
$ git clone public:git
...
$ git clone . public:git/mygit
...

I'd add some kind of cloneURL setter too, but the basic idea is this.

Regards:
-- 
Balazs Nagy