Re: What's cooking in gitweb (20 Sep 2008)

["Giuseppe Bilotta" <giuseppe.bilotta@gmail.com>]

On Mon, Sep 22, 2008 at 2:43 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> Giuseppe Bilotta wrote:
>>
>> 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.

This is fixed in the resend.

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

Generated urls now _always_ contain the action

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

Actually, the only reason I mentioned it would take time was to
explain why _that_ patch wouldn't be resent 'shortly' by me. I need to
study the log/shortlog/history code better to get an idea of what
might be a good refactoring strategy :)


-- 
Giuseppe "Oblomov" Bilotta