Re: [PATCH] gitweb: Different colours for tags and heads
- From
Jakub Narebski <jnareb@gmail.com>
- Date
- Aug 12, 2006, 00:12 UTC
- Message-ID
- <ebj6c3$4cj$1@sea.gmane.org>
- In-Reply-To
- <7vodurrlg8.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
Show 8 quoted lines
>> 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.
Show 16 quoted lines
>> 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.
Show 12 quoted lines
> 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