Re: [PATCH] gitweb: ref markers link to named shortlogs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Aug 24, 2008 at 10:37 PM, Jakub Narebski <jnareb@xxxxxxxxx> wrote:
> Lea Wiemann wrote:
>> Giuseppe Bilotta wrote:
>> > +                   my $git_type = git_get_type($ref);
>> > [...]
>> > +                           $cgi->a({-href => href(action=>$view{$git_type} || $git_type, hash=>$name)}, $name) .
>>
>> Since some of this thread seems to be about performance, you might just
>> make this a link to action => 'object' (and save the git_get_type call)
>> and let gitweb Do The Right Thing when the link is followed.
>>
>> [Disclaimer: Haven't read the whole thread, and haven't checked if
>> action=object is actually doing the right thing here.]
>
> First, only the first patch (and perhaps second) called git_get_type;
> v4 and v5 do not.  Second, link to 'object' action would not do the
> right thing; we want either 'shortlog' or 'tag' view, not 'commit'
> or 'tag' view.
>
> What this patch does is making ref markers in the log-like views, and
> in the commit subject line headers in other view be "hidden links" to
> either 'shortlog' (in the case of ref being head/branch, or lightweight
> tag), or to 'tag' view in the case of annotated tag.  We rely on the
> fact that we know what type of object refs points to (currently it is
> only 'commit', which might change, but the fact that we know type of
> object for which we show marker would not change), and the fact that
> tags point to given object only indirectly, and only tags can point
> indirectly (^{} suffix in "git show-ref --dereference", and
> "git ls-remote .", and $GIT_DIR/info/refs).

However, Lea's idea has its own merit. I hacked up a patch series that
implements a git_marker_view() function (or fucntion as the shortlog
says 8-P) and *that* one is used for ref markers, you can see it (3
patches) here: http://git.oblomov.eu/git/shortlog/heads/gitweb/shortlog..heads/gitweb/refmark
[it's on top of other stuff but it's actually independent from the
other stuff].

The advantage of this approach is that you actually it's more flexible
in case future expansions lead to other differences in object vs
marker view (currently the only difference is commit => shortlog):
such differences just need to be added to the appropriate %views hash.

The disadvantage is that we don't care about the difference between
lightweight and annotated tags, so there is no more visual difference
about it, something which patch v5 does. This could of course be
addressed separately as needed.

So, should I resend v5 with the small change about refs canonical
form, or is somebody else doing it? Or is the new idea as implemented
in the above mentioned changeset preferrable? Should I send that
patches to the mailing list?

Let me know, I've got plenty more stuff ready for gitweb and I'm eager
to see them accepted upstream 8-D

-- 
Giuseppe "Oblomov" Bilotta
--
To unsubscribe from this list: 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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux