On Thu, 26 Nov 2009, Junio C Hamano wrote: > Jakub Narebski <jnareb@xxxxxxxxx> writes: > > > Below there is request-pull with reordered series, unless you want me > > to resend this series as a set of patches, as reply to this email. > > It is too late for that, as they are already in 'next'. I do not think it > is necessary nor desirable, either. > > With the "Create links" commit, you are _adding_ a new link that leads to > a new feature with known breakage, not _replacing_ a link that leads to an > existing working implementation with one that does not work for some > people, no? No. The "Create links" commits make existing 'blame' links, which till that commit always lead to non-incremental 'blame' action, now lead to new 'blame_incremental' action (if JavaScript is enabled). So the result is that we _replace_ links to 'blame' view by links to 'blame_incremental' view. > Merging everything else but not merging that commit does not make any > sense. It won't give any wider exposure to the feature, and is no better > than carrying the entire thing in 'next' (or 'pu') post 1.6.6. > > A follow-up patch to add a gitweb configuration switch that disables the > non-working view by default but allows site owners to enable it in order > to help improving the feature would be a sensible thing to do. As long as > that patch is solidly done we can merge the whole thing to 'master' in the > upcoming release. But if it is already in 'next', then I'll try to come up with patch which makes JavaScript-ing links (replacing links with JavaScript to equivalent actions utilizing JavaScript, currently only 'blame' -> 'blame_incremental') configurable. -- Jakub Narebski Poland -- 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