From: Lea Wiemann <lewiemann@gmail.com>
To: Jakub Narebski <jnareb@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: [PATCH] gitweb: return correct HTTP status codes
Date: Wed, 18 Jun 2008 03:25:20 +0200 [thread overview]
Message-ID: <48586400.4000504@gmail.com> (raw)
In-Reply-To: <200806180212.15392.jnareb@gmail.com>
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
next prev parent reply other threads:[~2008-06-18 1:26 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-15 21:15 [PATCH] gitweb: return correct HTTP status codes Lea Wiemann
2008-06-15 22:48 ` Jakub Narebski
2008-06-16 15:57 ` Lea Wiemann
2008-06-16 16:43 ` Jakub Narebski
2008-06-16 21:49 ` Lea Wiemann
2008-06-16 22:34 ` Jakub Narebski
2008-06-17 13:53 ` Lea Wiemann
2008-06-16 22:38 ` Junio C Hamano
2008-06-17 14:04 ` Lea Wiemann
2008-06-17 14:33 ` Jakub Narebski
2008-06-17 22:28 ` Lea Wiemann
2008-06-17 22:54 ` Jakub Narebski
2008-06-17 23:47 ` Lea Wiemann
2008-06-18 0:12 ` Jakub Narebski
2008-06-18 1:25 ` Lea Wiemann [this message]
2008-06-18 7:35 ` Jakub Narebski
2008-06-16 23:37 ` Jakub Narebski
2008-06-18 0:15 ` [PATCH] gitweb: standarize " Lea Wiemann
2008-06-19 0:51 ` [PATCH v2] " Jakub Narebski
2008-06-19 19:08 ` Lea Wiemann
2008-06-19 20:03 ` [PATCH v3] " Lea Wiemann
2008-06-19 20:25 ` Lea Wiemann
2008-06-19 22:37 ` Jakub Narebski
2008-06-20 0:48 ` Junio C Hamano
2008-06-19 22:22 ` [PATCH v2] " Jakub Narebski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48586400.4000504@gmail.com \
--to=lewiemann@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jnareb@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).