From: "Nagy Balázs" <js@iksz•hu>
To: Jakub Narebski <jnareb@gmail•com>
Cc: Bruno Cesar Ribas <ribas@c3sl•ufpr.br>, git@vger•kernel.org
Subject: Re: [PATCH] Added sub get_owner_file which checks if there's a file with project owner name
Date: Fri, 01 Feb 2008 17:11:10 +0100 [thread overview]
Message-ID: <47A3449E.6070102@iksz.hu> (raw)
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
next prev parent reply other threads:[~2008-02-01 16:11 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-29 3:36 [PATCH] Added sub get_owner_file which checks if there's a file with project owner name Bruno Ribas
2008-01-29 11:26 ` Jakub Narebski
2008-01-29 14:25 ` Bruno Cesar Ribas
2008-01-29 15:28 ` Jakub Narebski
2008-01-29 17:22 ` Bruno Cesar Ribas
2008-01-29 18:27 ` Jakub Narebski
2008-01-29 20:53 ` Nagy Balázs
2008-01-29 21:36 ` Jakub Narebski
2008-01-30 15:59 ` Nagy Balázs
2008-02-01 13:18 ` Jakub Narebski
2008-02-01 16:11 ` Nagy Balázs [this message]
2008-02-01 19:10 ` Robin Rosenberg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=47A3449E.6070102@iksz.hu \
--to=js@iksz$(echo .)hu \
--cc=git@vger$(echo .)kernel.org \
--cc=jnareb@gmail$(echo .)com \
--cc=ribas@c3sl$(echo .)ufpr.br \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox