Re: [PATCH] gitweb.js: Harden setting blamed commit info in incremental blame
- From
Jakub Narebski <jnareb@gmail.com>
- Date
- Nov 26, 2009, 00:59 UTC
- Message-ID
- <200911260159.48311.jnareb@gmail.com>
- In-Reply-To
- <7vpr76m8dx.fsf@alter.siamese.dyndns.org>
On Thu, 26 Nov 2009, Junio C Hamano wrote:
Show 12 quoted lines
> Jakub Narebski <jnareb@gmail.com> 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.
Show 9 quoted lines
> 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