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@xxxxxxxxxxxxxxx/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@xxxxxxxxx>", 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@xxxxxxxxxxxxxxxxxxxx>, 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@xxxxxxxxx>
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
-
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
