Re: [RFC] gitweb: Add committags support (take 2)

From: Junio C Hamano <junkio@cox.net>
Date: Dec 4, 2006, 10:53 UTC
Message-ID: <7vmz64ortu.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <200612041133.44816.jnareb@gmail.com>

Jakub Narebski <jnareb@gmail.com> writes:

Show 14 quoted lines

> I have one gripe about "git-cat-file -t". I'd like it to have 
> -q/--quiet, -s/--silent, --hush (or --dont-spew-errors-on-stdout)
> which would prohibit writing "object not found" errors on stderr
> (and in gitweb case to webserver logs). I know I can use "git-cat-file -e"
> to check if object exists, or modify git_get_type subroutine
>
>   # get type of given object
>   sub git_get_type {
> 	my $hash = shift;
>   	my $git_command = git_cmd_str();
>   
>   	open my $fd, "-|",
>   		"$git_command cat-file -t $hash 2>/dev/null"
>   		or return '';

It is one thing if you tend to randomly throw garbage at this function and use it to check for object's existence, but I hope you are already checking the user input (which is what $hash is, I think, here), and the object is supposed to exist in the repository you are looking at. In such a case, I think you and your server administrator have right to know about that situation; I do not see why you would want to squelch it.

Show 14 quoted lines

>> I do not know how this %committags{} is used per project.  With
>> a setting like repo.or.cz, it is likely that one instance of
>> gitweb is serving unrelated projects that have their issue
>> tracker at different locations using different "committags"
>> convention.  Is the idea to eventually allow enabling/disabling
>> elements from the global %committags per repository somehow
>> (perhaps not just enable/disable but even overriding patterns or
>> parameters)?
>
> I have thought about putting %committags and @committags before
> loading config file
>   do $GITWEB_CONFIG if -e $GITWEB_CONFIG;
> which can load config file depending on the project, but perhaps
> it is too complicated solution.

I think you are talking about a gitweb-instance wide customization, but that's not what I meant. I meant per-project configuration where w/git-gui.git and w/git.git are served by the same instance of gitweb but have pointers to different issue trackers.

Show 10 quoted lines

>>> 3. To not split message into many fragments we concatenate strings
>>> if possible.
>> 
>> I do not know why "avoiding splits" is needed, if it raises 
>> issues that you need to ask the list about in a message like
>> this...
>
> "Avoiding splits" is needed first for performance, and second to
> avoid situation where pattern would match on the boundary between
> two strings in a list of tokens to process.

I wouldn't know if constantly splitting and then concatenating is faster than just concatenatting once before output without benchmarking, so I'd refrain from talking about performance. Two string case may be a valid concern, though.