Jakub Narebski <jnareb@gmail.com> writes:

quoted text
> 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.

quoted text
>> 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.

quoted text
>>> 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.

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html