Junio C Hamano wrote:
> Jakub Narebski <jnareb@xxxxxxxxx> 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
-
: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html