Re: What's cooking in gitweb (20 Sep 2008)
- From
Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
- Date
- Sep 22, 2008, 16:51 UTC
- Message-ID
- <cb7bb73a0809220951p5c19d19g2d79ecba0ef7e394@mail.gmail.com>
- In-Reply-To
- <200809221443.38689.jnareb@gmail.com>
On Mon, Sep 22, 2008 at 2:43 PM, Jakub Narebski <jnareb@gmail.com> wrote:
Show 17 quoted lines
> 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
Show 20 quoted lines
>> > 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