On Mon, Sep 22, 2008 at 2:43 PM, Jakub Narebski <jnareb@xxxxxxxxx> 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 -- 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
