From: Jakub Narebski <jnareb@gmail.com>
To: "Giuseppe Bilotta" <giuseppe.bilotta@gmail.com>
Cc: git@vger.kernel.org, "Lea Wiemann" <lewiemann@gmail.com>
Subject: Re: What's cooking in gitweb (20 Sep 2008)
Date: Mon, 22 Sep 2008 14:43:37 +0200 [thread overview]
Message-ID: <200809221443.38689.jnareb@gmail.com> (raw)
In-Reply-To: <cb7bb73a0809211322q5aa6d8ex88651aa33a6c2688@mail.gmail.com>
Giuseppe Bilotta wrote:
> > 1. "gitweb pathinfo improvements" by Giuseppe Bilotta
[...]
> > Need some refinement, especially with respect to _generating_
> > path_info URLs inside gitweb. Some patches (2 and 5) does not
> > need correction, and probably should be sent as separate series.
> > Author promised to resend series, if I remember correctly.
>
> I'll resend the whole series (plus an additional patch to fix an
> aesthetical issue I found recently) as soon as I fix the url
> generation for the dotted filename corner case (which by re-reading
> the past emails seemed to be the only significant issue, correct?).
I think it was the only significant issue (besides the fact that
two mentioned patches could be in separate series). To be more
exact the issue was with generating gitweb URLs for sets of
parameters which cannot be represented as path_info URL. One
example was filename with '..' in it, which cannot be used in
the following path_info form:
$hash_parent_base:$file_parent..$hash_base:$filename
but it can be used in 'no name change' form
$hash_parent_base..$hash_base:$filename
This requires fallback to 'query' form URL.
Other example was branch name with the same name as one of gitweb
actions, which require action to be stated explicitly even if it
is default action and otherwise could be omitted.
> Should be shortly.
I see that it is now. Thanks.
> > 2. "[PATCH] gitweb: shortlog now also obeys $hash_parent"
> > by Giuseppe Bilotta
[...]
> > More important fact is that I'd very much like for _all_ log-like
> > views (perhaps with exception of feeds: Atom and RSS) to implement
> > this feature. This could be done by either doing it all in the same
> > commit, doing commit series changing 'shortlog', 'log' and 'history'
> > separately, or what I would prefer actually, to refactor generation
> > of log-like views to use single worker/engine subroutine.
>
> I agree that refactoring is probably the best idea. It will also take
> me some more time ;)
But it has the advantage of making it easier to add more log-like
views, like 'log' like view for the 'history' view, i.e. --pretty=full
like view with path limiting.
I have thought about doing the refactoring (it is/was on my long-term
TODO list for gitweb), but I haven't even found good way to code it,
to be flexible but not too generalized. Callbacks, perhaps?
> BTW, I haven't heard from Lea, so can I just assume that my patches
> don't touch any of her caching improvements?
--
Jakub Narebski
Poland
next prev parent reply other threads:[~2008-09-22 12:45 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-20 23:38 What's cooking in gitweb (20 Sep 2008) Jakub Narebski
2008-09-21 4:54 ` Junio C Hamano
2008-09-21 20:22 ` Giuseppe Bilotta
2008-09-22 12:43 ` Jakub Narebski [this message]
2008-09-22 16:51 ` Giuseppe Bilotta
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=200809221443.38689.jnareb@gmail.com \
--to=jnareb@gmail.com \
--cc=git@vger.kernel.org \
--cc=giuseppe.bilotta@gmail.com \
--cc=lewiemann@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).