Re: [PATCH 0/3] gitweb: Simplify some gitweb URLs generation

From: Jakub Narebski <jnareb@gmail.com>
Date: Nov 2, 2007, 00:18 UTC
Message-ID: <200711020118.44015.jnareb@gmail.com>
In-Reply-To: <7v1wb98twi.fsf@gitster.siamese.dyndns.org>

Junio C Hamano wrote:

Show 19 quoted lines

> Jakub Narebski <jnareb@gmail.com> writes:
> 
>> This series of patches simplifies some gitweb URLs generation by
>> providing -replay option to href() subroutine, and then using this
>> feature in gitweb code.
>>
>> Shortlog:
>>  gitweb: Easier adding/changing parameters to current URL
>>  gitweb: Use href(-replay=>1, page=>...) to generate pagination links
>>  gitweb: Use href(-replay=>1, action=>...) to generate alternate views
>>
>> Diffstat:
>>  gitweb/gitweb.perl |   82 ++++++++++++++++++++++-----------------------------
>>  1 files changed, 35 insertions(+), 47 deletions(-)
> 
> If this "-replay" is used carelessly, it could add parameters
> that were passed to the page that the original code stripped
> away from passing on purpose.  Have you checked if the
> conversion done with 2/3 and 3/3 are correct (I haven't)?

First, I guess that I should have marked this series of patches as an RFC, but not for the reason you mentioned. This series changes somewhat gitweb behaviour (patches 2/3 and 3/3 to be more exact) in a way that before gitweb passed 'expanded' hashes to page / alternate view links. For example before this series link to second page for shortlog view starting from 'HEAD' passed literal sha1 for 'h' parameter, ans second page started where first page ended. After this patch, if refs have changed between viewing first page and clicking on the link to second page, the resulting view would be second page of _new_ 'HEAD', not of old (shown) 'HEAD'.

Second, you do not need to worry about adding parameters, because in 2/3 and 3/3 -replay is used to change view to the one which differs from current by one parameter. Please take into account that some parameters are just not important.

-- 
Jakub Narebski
Poland