Re: [PATCHv3 2/4] gitweb: git_get_heads_list accepts an optional list of refs.

[Junio C Hamano <gitster@pobox.com>]

Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:

> git_get_heads_list(limit, class1, class2, ...) can now be used to retrieve
> refs/class1, refs/class2 etc. Defaults to ('heads') or ('heads', 'remotes')
> depending on the remote_heads option.
>
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
> ---
>  gitweb/gitweb.perl |   11 +++++++----
>  1 files changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index e1f81f6..0512020 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -2681,15 +2681,18 @@ sub parse_from_to_diffinfo {
>  ## parse to array of hashes functions
>  
>  sub git_get_heads_list {
> -	my $limit = shift;
> +	my ($limit, @class) = @_;
> +	unless (defined @class) {
> +		my $remote_heads = gitweb_check_feature('remote_heads');
> +		@class = ('heads', $remote_heads ? 'remotes' : undef);
> +	}
> +	my @refs = map { "refs/$_" } @class;

Makes sense, except that I'd suggest passing a hash of "refs/$path" =>
$class as I illustrated in my comments to [1/4], instead of passing a list
of ("head", "remote"), because that will later allow you to have
multi-level $path that does not necessarily limited to a $class that is a
substring of $path, and doing so does not make the code any more complex.
There is another reason to do so I'll mention in I comment on [3/4].