Re: [PATCH] gitweb: Different colours for tags and heads

[Jakub Narebski <jnareb@gmail.com>]

Junio C Hamano wrote:

> Jakub Narebski <jnareb@gmail.com> writes:

>> I've planned on patch which does something similar to
>> yours, but in slightly different way: instead of two calls 
>> to git_get_referencing (format_mark_referencing[*1*] after rename)
>> and two calls to read_info_ref (git_get_references after rename)
>> in your patch, read_info_ref would always add full name, of
>> which first component is the type of the tag.
> 
> get_referencing to get, and format_ref to format perhaps?

Thanks for a suggestion. I've decided on git_get_references, and
format_ref_marker,but it isn't cast in stone.
 
>> I am wondering if to do this like in my abovementioned patch,
>> putting references in single string, separated by ':' (':' cannot
>> be part of valid ref name), or use array (anonymous array reference
>> to be more exact). 
> 
> Two things and half come to mind.
> 
> get_referencing could get and return the full refname without
> abbreviation ('heads/jn/web' or 'tags/v1.0'), and the caller can
> do whatever with them (e.g. see what the name begins with to
> tell heads and tags apart).  This is probably the most flexible
> if we do not want to cast the categorization of refs in stone.
> 
> Otherwise, return an arrayref, like ['tag', 'v1.0', 'v1.0'] or
> ['head', 'web', 'jn/web'], to say what kind, short name and full
> name.

Perhaps I have not said things clearly. The problem I meant to solve is the
fact that there might be more than one ref pointing to a given object.
Currently read_info_ref does not its job joining references pointing to
given object (referenced object is key of a hash) using " / ", i.e.
creating the "joined tag".

In dropped patch I've mentioned I joined references using ':' as it can't be
part of valid ref name, then split it on ':' on formatting.

But they can be put into anonymous arrayref (e.g. ['heads/next',
'heads/autoconf'] at the start of 'autoconf' branch, or ['heads/master',
'heads/next', 'tags/v1.4.2'], not 'heads/master:heads/next:tags/v1.4.2'
my patch did.

> I've always wondered if the span that shows the short refname
> could have an on-hover pop-up (title attribute is often shown
> that way) to show the full name.  Then you could do something
> like:
> 
>     $long_name = 'heads/jn/web'; # or 'tags/v1.0'
>     $kind = ($long_name =~ /^heads/) ? 'head' : 'tag';
>     $long_name = s|^[^/]*/||;
>     ($short_name = $long_name) =~ s|.*/||;
>     $long_name = esc_html($long_name);
>     $short_name = esc_html($short_name);
>     return " <span class='$kind' title='$long_name'>$short_name</span>";

Currently (in core-git) besides 'heads' and 'tags' there might be
'remotes' (when using --use-separate-remote' option of git-clone), all
following the rule of being plural (in English) to the type of tag, so one
could use
        $ref =~ m|(^[^/])*s?/|;
        $kind = $1;
for kind.

By the way, is it really usefull to have shortened ref name, e.g. 'web' for
'jn/web'? That is what gitweb does currently (only without giving ling name
at all). It is probably bad practice, but I've had branches ab/sth and
zz/sth, with the same shortname.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git