Jakub Narebski <jnareb@xxxxxxxxx> writes:
> 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.
>> 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.
>>> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html