Junio C Hamano <gitster@xxxxxxxxx> writes: > Junio C Hamano <gitster@xxxxxxxxx> writes: > >> Bruno Cesar Ribas <ribas@xxxxxxxxxxxx> writes: >> ... >>> Opening the extra file has same problem as the description file. And, as >>> gitweb allow us to create "description" and "cloneurl" file there is no >>> problem having another file to open instead finding out who is the owner of >>> the directory asking to the filesystem. >> >> We heard the same argument when cloneurl was added, and a >> newcomer who does not know that may rightly use the same >> argument. But I think we should work towards _reducing_ the >> number of such ad-hoc one-line-per-information files, not using >> existing ones as an excuse to add _more_ of them. > > Rephrasing to be constructive (but remember, this is all post > 1.5.4). > > * we would need for historical reasons to keep supporting > description and cloneurl for some time. There may be some > others, but the goal should be to deprecate and remove these > ad-hoc one-file-per-piece-of-information files. > > * we also need for historical reasons to keep supporting some > other stuff found in $git_dir/config of the project. > > If the config reading interface in gitweb is reasonably fast and > cheap, we can move the existing description/cloneurl to gitweb > config when deprecating them. New ones such as "owner" would > naturally fit there. Currently gitweb parses repo config file _once_, using one call to git-config -z -l. We could simply add description to the projects_list file, but it will be a bit backwards incompatibile change. We have to call at least one git-for-each-ref per repo to get last update date, by the way. > If the config reading interface is too slow (somebody has to > bench it on a large set of repositories), maybe we would need to > optimize _THAT_. If it turns out to be unreasonable (e.g. we > may really want to keep the implementation that spawns "git > config" to do the work, rather than writing and having to > maintain a pure Perl version of config parser inside gitweb, > which is a reasonable position to take in the longer run, but > spawning a process per repository may be too expensive). While IIRC cvsimport or cvsserver has its own config parser in Perl, but which accepts only limited sensible subset of configuration syntax (and IIRC uses separate config file). -- Jakub Narebski Poland ShadeHawk on #git - 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
