Re: [PATCH] gitweb: return correct HTTP status codes

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

 



Jakub Narebski wrote:
Lea Wiemann wrote:
$hash = get_hash($symbol, 'commit'); # 'commit' to resolve tags

Errr... is there equivalent to ^{}, i.e. resolve to non-tag?

Yup. Haven't quite decided whether to simply use "$symbol^{type}" or make type a separate parameter.

Note that you would have to examine gitweb sources to check if it
uses href(..., -replay=>1) when it should,

Good point, will do.

BTW. one of earliest idea was to fully resolve hashes, add missing
parameters if possible (like 'h', 'hp', 'f') and convert hashes to
sha-1.  One of intended uses was (weak) ETag for simple HTTP caching.

Interesting. Something to keep in mind is that using name-rev still can wreck with this since it has the unique property of taking hashes but still depending on the current refs. Gitweb isn't using name-rev a lot right now, but that might change of course (e.g. I think that it would be convenient to always display names along with any commit hashes).

All the time I think that caching _everything_ is a bad solution.

So? We can easily add an option to the cache; e.g. no_cache => ['get_blob', 'ls_tree']. I doubt that it will be needed, but if it does, it's easy to add it. Don't worry about it, really.

CHI (or other in recommended thread) for inobtrusive data caching

Thanks for the pointer! On the one hand CHI is very recent and not even in Debian, on the other hand it provides things like busy_lock on top of Memcached (AFAICS), at fairly little cost. I'll look into it.

-- Lea
--
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