Re: [PATCH/RFC] gitweb: Great subroutines renaming

From: Junio C Hamano <junkio@cox.net>
Date: Aug 7, 2006, 22:00 UTC
Message-ID: <7v4pwo1a0r.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <eb8cdh$s6n$1@sea.gmane.org>

Jakub Narebski <jnareb@gmail.com> writes:

Show 17 quoted lines

> Currently after rename we have the following git_read_* functions
>
> * git_read_info_refs, which reads .git/info/refs directly and relies on it's
> format
> * git_read_hash which translates ref to hash by reading ref file
> (e.g. .git/refs/heads/master) which means that it doesn't support symrefs
> yet; but first, it should be easy to implement without invoking any git
> command, and second, there are usually no symrefs beside HEAD, and I'm not
> sure that git would work with non-HEAD symref.
> * git_read_refs (or rather git_readdir_refs) which reads .git/refs directory
> * git_read_projects (or rather git_readdir_projects) which checks for
> projects checking if HEAD file exists
> * git_read_description which reads .git/description; but in the future
> description might be stored in repository config
>
> What is also important is the fast that git_read_* functions are fast,
> with exception of git_read_info_refs...

Hmph. readdir-refs is quite bad for future compatibility, so is read_hash.

If you want _fast_ then make the implementation fast (or leave room to make it fast later); encoding the fastness assumption in the name IS WRONG.

For example, sub git_get_hash (not git_read_hash) can stay as (potentially buggy wrt symrefs) "reading from .git/refs/$thing" or could even be fixed to read from git-rev-parse (which is the kosher way). If it turns out to be a bottleneck, it could be rewritten using Git.xs. The same thing for read_refs which I think should be doing ls-remote on the repository if it wants to be kosher.

Show 7 quoted lines

>> The problem is when...
>
> With two scripts attached to the first post in this thread it would be
> simple to apply pre-rename patch, by converting gitweb to pre-rename using
> gitweb-unrename.sh script, then applying patch, then restoring new names
> using gitweb-rename.sh script, and finally comitting changes (or amending
> commit).

That assumes the rename be done now, and nobody introduces new functions following old naming convention in the meantime.