On Thu, 18 Dec 2008, Junio C Hamano wrote:
> Giuseppe Bilotta <giuseppe.bilotta@xxxxxxxxx> writes:
>
> > sub git_commitdiff {
> > my $format = shift || 'html';
> > + my %params = @_;
> > ...
> > + if ($params{-single}) {
> > + push @commit_spec, '-1';
> > + } else {
> > + if ($patch_max > 0) {
> > ...
> > + }
> > @@ -5625,6 +5635,10 @@ sub git_commitdiff_plain {
> >
> > # format-patch-style patches
> > sub git_patch {
> > + git_commitdiff('patch', -single=> 1);
> > +}
>
> Hmm, if you are changing the interface this way, wouldn't it make more
> sense to also do this?
>
> git_commitdiff(--format => 'patch', --single => 1);
> git_commitdiff(--format => 'html');
Just a though, but does it really take much sense to have "patch" and
"patches" views handled in git_commitdiff? I can understand in the
first version, where it was more about better 'commitdiff_plain', but
I wonder about now, where patch(es) view is something between git show
and log_plain format... Wouldn't it be simpler to use separate
subroutine, for example git_format_patch or something?
--
Jakub Narebski
Poland
--
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
