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

From: Jakub Narebski <[email-masked]>
Date: Mon, 07 Aug 2006 23:47:37 +0200

Junio C Hamano wrote:

> Jakub Narebski <[email-masked]> writes:
> 
>> This RFC is about better naming of subroutines in gitweb. The patch was
>> generated on top of 'next' (7c7e45d0cc0f482aeb19ecb0b56e9e7b65472c56)
>> using embedded gitweb-rename.sh script.
[...]
>> * git_read_ prefix for subroutines directly accessing git
>>   repository files
> 
>  - (I am not complaining or objecting yet -- this is just an
>    observation. ) The distinction between git_get_foo and
>    git_read_foo is an implementation detail.  The latter could
>    signal that the implementation bypasses the published
>    interface but depends on the implementation detail of the
>    low-level git, so it might be a good idea, but on the other
>    hand the only instance is git_read_info_refs which reads from
>    .git/info/refs -- and its format is part of the published
>    interface -- so I am not so sure this distinction is worth
>    it.  And certainly we would not want to rely too heavily on
>    the current implementation of the low-level git, so we
>    obviously do not want to add more git_read_foo's needlessly,
>    which makes me feel even less sure if we would want
>    git_read_foo...

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...

[...]
> If we are to have many more fixes and clean-ups on gitweb,
> readable and consistent names would be very helpful.
> 
> The problem is when.  If we are going to apply this, we need to
> pick a point of time when not many patches on gitweb are in
> flight; otherwise I'd end up asking people to resend using new
> names.

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).

But I agree that it would be best to do "subroutine renaming" during lull in
gitweb development.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git