{"thread":{"id":"16736","subject":"[PATCH] gitweb: make feature_blame return a list","startedAt":"2008-12-15T14:51:48Z","lastAt":"2008-12-17T08:20:27Z","messageCount":13,"participants":["Matt Kraai","Junio C Hamano","Giuseppe Bilotta","Petr Baudis"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"97964","messageId":"1229352709-4663-1-git-send-email-kraai@ftbfs.org","threadId":"16736","inReplyTo":null,"subject":"[PATCH] gitweb: make feature_blame return a list","fromName":"Matt Kraai","fromEmail":"kraai@ftbfs.org","sentAt":"2008-12-15T14:51:48Z","receivedAt":"2008-12-15T14:51:48Z","isPatch":true,"sender":{"key":"kraai@ftbfs.org","avatar":null},"body":"The feature defaults are expected to be a list, but feature_blame was\nreturning a scalar.  This change makes it consistent with the other\nboolean feature subroutines.\n\nSigned-off-by: Matt Kraai <kraai@ftbfs.org>\n---\n gitweb/gitweb.perl |    6 +++---\n 1 files changed, 3 insertions(+), 3 deletions(-)\n\ndiff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl\nindex 6eb370d..145e712 100755\n--- a/gitweb/gitweb.perl\n+++ b/gitweb/gitweb.perl\n@@ -367,12 +367,12 @@ sub feature_blame {\n \tmy ($val) = git_get_project_config('blame', '--bool');\n \n \tif ($val eq 'true') {\n-\t\treturn 1;\n+\t\treturn (1);\n \t} elsif ($val eq 'false') {\n-\t\treturn 0;\n+\t\treturn (0);\n \t}\n \n-\treturn $_[0];\n+\treturn ($_[0]);\n }\n \n sub feature_snapshot {\n-- \n1.5.6.5\n"},{"id":"97965","messageId":"1229352709-4663-2-git-send-email-kraai@ftbfs.org","threadId":"16736","inReplyTo":"1229352709-4663-1-git-send-email-kraai@ftbfs.org","subject":"[PATCH] gitweb: unify boolean feature subroutines","fromName":"Matt Kraai","fromEmail":"kraai@ftbfs.org","sentAt":"2008-12-15T14:51:49Z","receivedAt":"2008-12-15T14:51:49Z","isPatch":true,"sender":{"key":"kraai@ftbfs.org","avatar":null},"body":"The boolean feature subroutines were identical except for the name of\nthe configuration option, so make that a parameter and unify them.\n\nSigned-off-by: Matt Kraai <kraai@ftbfs.org>\n---\n gitweb/gitweb.perl |   35 ++++++-----------------------------\n 1 files changed, 6 insertions(+), 29 deletions(-)\n\ndiff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl\nindex 145e712..827e5c5 100755\n--- a/gitweb/gitweb.perl\n+++ b/gitweb/gitweb.perl\n@@ -203,7 +203,7 @@ our %feature = (\n \t# $feature{'blame'}{'override'} = 1;\n \t# and in project config gitweb.blame = 0|1;\n \t'blame' => {\n-\t\t'sub' => \\&feature_blame,\n+\t\t'sub' => sub { feature_bool('blame', @_) },\n \t\t'override' => 0,\n \t\t'default' => [0]},\n \n@@ -241,7 +241,7 @@ our %feature = (\n \t# $feature{'grep'}{'override'} = 1;\n \t# and in project config gitweb.grep = 0|1;\n \t'grep' => {\n-\t\t'sub' => \\&feature_grep,\n+\t\t'sub' => sub { feature_bool('grep', @_) },\n \t\t'override' => 0,\n \t\t'default' => [1]},\n \n@@ -255,7 +255,7 @@ our %feature = (\n \t# $feature{'pickaxe'}{'override'} = 1;\n \t# and in project config gitweb.pickaxe = 0|1;\n \t'pickaxe' => {\n-\t\t'sub' => \\&feature_pickaxe,\n+\t\t'sub' => sub { feature_bool('pickaxe', @_) },\n \t\t'override' => 0,\n \t\t'default' => [1]},\n \n@@ -363,8 +363,9 @@ sub gitweb_check_feature {\n }\n \n \n-sub feature_blame {\n-\tmy ($val) = git_get_project_config('blame', '--bool');\n+sub feature_bool {\n+\tmy $key = shift;\n+\tmy ($val) = git_get_project_config($key, '--bool');\n \n \tif ($val eq 'true') {\n \t\treturn (1);\n@@ -387,30 +388,6 @@ sub feature_snapshot {\n \treturn @fmts;\n }\n \n-sub feature_grep {\n-\tmy ($val) = git_get_project_config('grep', '--bool');\n-\n-\tif ($val eq 'true') {\n-\t\treturn (1);\n-\t} elsif ($val eq 'false') {\n-\t\treturn (0);\n-\t}\n-\n-\treturn ($_[0]);\n-}\n-\n-sub feature_pickaxe {\n-\tmy ($val) = git_get_project_config('pickaxe', '--bool');\n-\n-\tif ($val eq 'true') {\n-\t\treturn (1);\n-\t} elsif ($val eq 'false') {\n-\t\treturn (0);\n-\t}\n-\n-\treturn ($_[0]);\n-}\n-\n # checking HEAD file with -e is fragile if the repository was\n # initialized long time ago (i.e. symlink HEAD) and was pack-ref'ed\n # and then pruned.\n-- \n1.5.6.5\n"},{"id":"98006","messageId":"7v7i61w06k.fsf@gitster.siamese.dyndns.org","threadId":"16736","inReplyTo":"1229352709-4663-1-git-send-email-kraai@ftbfs.org","subject":"Re: [PATCH] gitweb: make feature_blame return a list","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-12-15T22:20:03Z","receivedAt":"2008-12-15T22:20:03Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matt Kraai <kraai@ftbfs.org> writes:\n\n> The feature defaults are expected to be a list, but feature_blame was\n> returning a scalar.  This change makes it consistent with the other\n> boolean feature subroutines.\n>\n> Signed-off-by: Matt Kraai <kraai@ftbfs.org>\n> ---\n>  gitweb/gitweb.perl |    6 +++---\n>  1 files changed, 3 insertions(+), 3 deletions(-)\n>\n> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl\n> index 6eb370d..145e712 100755\n> --- a/gitweb/gitweb.perl\n> +++ b/gitweb/gitweb.perl\n> @@ -367,12 +367,12 @@ sub feature_blame {\n>  \tmy ($val) = git_get_project_config('blame', '--bool');\n>  \n>  \tif ($val eq 'true') {\n> -\t\treturn 1;\n> +\t\treturn (1);\n>  \t} elsif ($val eq 'false') {\n> -\t\treturn 0;\n> +\t\treturn (0);\n>  \t}\n>  \n> -\treturn $_[0];\n> +\treturn ($_[0]);\n>  }\n\nMy Perl may be getting rusty, but does the above make any difference?\nHow?\n"},{"id":"98007","messageId":"7v3agpw04m.fsf@gitster.siamese.dyndns.org","threadId":"16736","inReplyTo":"1229352709-4663-2-git-send-email-kraai@ftbfs.org","subject":"Re: [PATCH] gitweb: unify boolean feature subroutines","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-12-15T22:21:13Z","receivedAt":"2008-12-15T22:21:13Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matt Kraai <kraai@ftbfs.org> writes:\n\n> The boolean feature subroutines were identical except for the name of\n> the configuration option, so make that a parameter and unify them.\n\nI think this makes sense but unfortunately it comes after the other one\nthat I do not know what its point is...\n"},{"id":"98008","messageId":"gi6n3m$kvc$1@ger.gmane.org","threadId":"16736","inReplyTo":"7v7i61w06k.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] gitweb: make feature_blame return a list","fromName":"Giuseppe Bilotta","fromEmail":"giuseppe.bilotta@gmail.com","sentAt":"2008-12-15T22:52:38Z","receivedAt":"2008-12-15T22:52:38Z","isPatch":true,"sender":{"key":"giuseppe.bilotta@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1464?v=4"},"body":"On Monday 15 December 2008 23:20, Junio C Hamano wrote:\n\n> Matt Kraai <kraai@ftbfs.org> writes:\n> \n>> The feature defaults are expected to be a list, but feature_blame was\n>> returning a scalar.  This change makes it consistent with the other\n>> boolean feature subroutines.\n>>\n>> Signed-off-by: Matt Kraai <kraai@ftbfs.org>\n>> ---\n>>  gitweb/gitweb.perl |    6 +++---\n>>  1 files changed, 3 insertions(+), 3 deletions(-)\n>>\n>> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl\n>> index 6eb370d..145e712 100755\n>> --- a/gitweb/gitweb.perl\n>> +++ b/gitweb/gitweb.perl\n>> @@ -367,12 +367,12 @@ sub feature_blame {\n>>      my ($val) = git_get_project_config('blame', '--bool');\n>>  \n>>      if ($val eq 'true') {\n>> -            return 1;\n>> +            return (1);\n>>      } elsif ($val eq 'false') {\n>> -            return 0;\n>> +            return (0);\n>>      }\n>>  \n>> -    return $_[0];\n>> +    return ($_[0]);\n>>  }\n> \n> My Perl may be getting rusty, but does the above make any difference?\n> How?\n\nIt's formally more correct and makes the blame feature fit with the\ngeneral feature framework, although the feature works correctly even\nwithout the (). I was actually going to send a similar patch myself, \nhaving missed it during the cleanup and get/check splitup patchset.\n\nMatt's patch gets my Ack, for what it's worth.\n\n\n-- \nGiuseppe \"Oblomov\" Bilotta\n"},{"id":"98029","messageId":"20081216024605.GA4529@ftbfs.org","threadId":"16736","inReplyTo":"7v7i61w06k.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] gitweb: make feature_blame return a list","fromName":"Matt Kraai","fromEmail":"kraai@ftbfs.org","sentAt":"2008-12-16T02:46:05Z","receivedAt":"2008-12-16T02:46:05Z","isPatch":true,"sender":{"key":"kraai@ftbfs.org","avatar":null},"body":"On Mon, Dec 15, 2008 at 02:20:03PM -0800, Junio C Hamano wrote:\n> Matt Kraai <kraai@ftbfs.org> writes:\n> > --- a/gitweb/gitweb.perl\n> > +++ b/gitweb/gitweb.perl\n> > @@ -367,12 +367,12 @@ sub feature_blame {\n> >  \tmy ($val) = git_get_project_config('blame', '--bool');\n> >  \n> >  \tif ($val eq 'true') {\n> > -\t\treturn 1;\n> > +\t\treturn (1);\n> >  \t} elsif ($val eq 'false') {\n> > -\t\treturn 0;\n> > +\t\treturn (0);\n> >  \t}\n> >  \n> > -\treturn $_[0];\n> > +\treturn ($_[0]);\n> >  }\n> \n> My Perl may be getting rusty, but does the above make any difference?\n\nI'm still relatively new to Perl, but at least in my limited testing,\nI couldn't generate a case in which these different constructs had\ndifferent results.\n\nI made this change so that all of the boolean feature subroutines\nwould have the same body, modulo the name of the option; that way,\nreplacing them with a single routine only involves making the option\nname a parameter.\n\nIf you'd like me to resubmit my second patch, I'm happy to do so.\nJust let me know whether you prefer the resulting function to wrap its\nreturn values in parentheses (as is currently done by feature_grep and\nfeature_pickaxe) or not.\n\n-- \nMatt                                                 http://ftbfs.org/\n"},{"id":"98041","messageId":"7vabawu1ao.fsf@gitster.siamese.dyndns.org","threadId":"16736","inReplyTo":"20081216024605.GA4529@ftbfs.org","subject":"Re: [PATCH] gitweb: make feature_blame return a list","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-12-16T05:38:55Z","receivedAt":"2008-12-16T05:38:55Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matt Kraai <kraai@ftbfs.org> writes:\n\n> If you'd like me to resubmit my second patch, I'm happy to do so.\n> Just let me know whether you prefer the resulting function to wrap its\n> return values in parentheses (as is currently done by feature_grep and\n> feature_pickaxe) or not.\n\nSure, keeping what feature_grep does is just fine.\n\nThanks.\n"},{"id":"98043","messageId":"1229408179-7655-1-git-send-email-kraai@ftbfs.org","threadId":"16736","inReplyTo":"7vabawu1ao.fsf@gitster.siamese.dyndns.org","subject":"[PATCH] gitweb: unify boolean feature subroutines","fromName":"Matt Kraai","fromEmail":"kraai@ftbfs.org","sentAt":"2008-12-16T06:16:19Z","receivedAt":"2008-12-16T06:16:19Z","isPatch":true,"sender":{"key":"kraai@ftbfs.org","avatar":null},"body":"The boolean feature subroutines behaved identically except for the\nname of the configuration option, so make that a parameter and unify\nthem.\n\nSigned-off-by: Matt Kraai <kraai@ftbfs.org>\n---\n gitweb/gitweb.perl |   41 +++++++++--------------------------------\n 1 files changed, 9 insertions(+), 32 deletions(-)\n\ndiff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl\nindex 6eb370d..827e5c5 100755\n--- a/gitweb/gitweb.perl\n+++ b/gitweb/gitweb.perl\n@@ -203,7 +203,7 @@ our %feature = (\n \t# $feature{'blame'}{'override'} = 1;\n \t# and in project config gitweb.blame = 0|1;\n \t'blame' => {\n-\t\t'sub' => \\&feature_blame,\n+\t\t'sub' => sub { feature_bool('blame', @_) },\n \t\t'override' => 0,\n \t\t'default' => [0]},\n \n@@ -241,7 +241,7 @@ our %feature = (\n \t# $feature{'grep'}{'override'} = 1;\n \t# and in project config gitweb.grep = 0|1;\n \t'grep' => {\n-\t\t'sub' => \\&feature_grep,\n+\t\t'sub' => sub { feature_bool('grep', @_) },\n \t\t'override' => 0,\n \t\t'default' => [1]},\n \n@@ -255,7 +255,7 @@ our %feature = (\n \t# $feature{'pickaxe'}{'override'} = 1;\n \t# and in project config gitweb.pickaxe = 0|1;\n \t'pickaxe' => {\n-\t\t'sub' => \\&feature_pickaxe,\n+\t\t'sub' => sub { feature_bool('pickaxe', @_) },\n \t\t'override' => 0,\n \t\t'default' => [1]},\n \n@@ -363,16 +363,17 @@ sub gitweb_check_feature {\n }\n \n \n-sub feature_blame {\n-\tmy ($val) = git_get_project_config('blame', '--bool');\n+sub feature_bool {\n+\tmy $key = shift;\n+\tmy ($val) = git_get_project_config($key, '--bool');\n \n \tif ($val eq 'true') {\n-\t\treturn 1;\n+\t\treturn (1);\n \t} elsif ($val eq 'false') {\n-\t\treturn 0;\n+\t\treturn (0);\n \t}\n \n-\treturn $_[0];\n+\treturn ($_[0]);\n }\n \n sub feature_snapshot {\n@@ -387,30 +388,6 @@ sub feature_snapshot {\n \treturn @fmts;\n }\n \n-sub feature_grep {\n-\tmy ($val) = git_get_project_config('grep', '--bool');\n-\n-\tif ($val eq 'true') {\n-\t\treturn (1);\n-\t} elsif ($val eq 'false') {\n-\t\treturn (0);\n-\t}\n-\n-\treturn ($_[0]);\n-}\n-\n-sub feature_pickaxe {\n-\tmy ($val) = git_get_project_config('pickaxe', '--bool');\n-\n-\tif ($val eq 'true') {\n-\t\treturn (1);\n-\t} elsif ($val eq 'false') {\n-\t\treturn (0);\n-\t}\n-\n-\treturn ($_[0]);\n-}\n-\n # checking HEAD file with -e is fragile if the repository was\n # initialized long time ago (i.e. symlink HEAD) and was pack-ref'ed\n # and then pruned.\n-- \n1.5.6.5\n"},{"id":"98047","messageId":"1229412998-8385-1-git-send-email-kraai@ftbfs.org","threadId":"16736","inReplyTo":"1229408179-7655-1-git-send-email-kraai@ftbfs.org","subject":"[PATCH] gitweb: pass the option name to the feature callback","fromName":"Matt Kraai","fromEmail":"kraai@ftbfs.org","sentAt":"2008-12-16T07:36:38Z","receivedAt":"2008-12-16T07:36:38Z","isPatch":true,"sender":{"key":"kraai@ftbfs.org","avatar":null},"body":"The feature_bool callback required the option name to be passed to\nit.  Make gitweb_get_feature do so instead of constructing an\nanonymous subroutine for each overrideable boolean option.\n\nSigned-off-by: Matt Kraai <kraai@ftbfs.org>\n---\n gitweb/gitweb.perl |   12 ++++++------\n 1 files changed, 6 insertions(+), 6 deletions(-)\n\n   Sorry for the churn; I read the corresponding part of Higher-Order\n   Perl *after* sending my previous patches.  :(\n\n   If I should squash this into my previous patch and resubmit it,\n   please let me know.\n\ndiff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl\nindex 827e5c5..3459293 100755\n--- a/gitweb/gitweb.perl\n+++ b/gitweb/gitweb.perl\n@@ -203,7 +203,7 @@ our %feature = (\n \t# $feature{'blame'}{'override'} = 1;\n \t# and in project config gitweb.blame = 0|1;\n \t'blame' => {\n-\t\t'sub' => sub { feature_bool('blame', @_) },\n+\t\t'sub' => \\&feature_bool,\n \t\t'override' => 0,\n \t\t'default' => [0]},\n \n@@ -241,7 +241,7 @@ our %feature = (\n \t# $feature{'grep'}{'override'} = 1;\n \t# and in project config gitweb.grep = 0|1;\n \t'grep' => {\n-\t\t'sub' => sub { feature_bool('grep', @_) },\n+\t\t'sub' => \\&feature_bool,\n \t\t'override' => 0,\n \t\t'default' => [1]},\n \n@@ -255,7 +255,7 @@ our %feature = (\n \t# $feature{'pickaxe'}{'override'} = 1;\n \t# and in project config gitweb.pickaxe = 0|1;\n \t'pickaxe' => {\n-\t\t'sub' => sub { feature_bool('pickaxe', @_) },\n+\t\t'sub' => \\&feature_bool,\n \t\t'override' => 0,\n \t\t'default' => [1]},\n \n@@ -344,7 +344,7 @@ sub gitweb_get_feature {\n \t\twarn \"feature $name is not overrideable\";\n \t\treturn @defaults;\n \t}\n-\treturn $sub->(@defaults);\n+\treturn $sub->($name, @defaults);\n }\n \n # A wrapper to check if a given feature is enabled.\n@@ -377,9 +377,9 @@ sub feature_bool {\n }\n \n sub feature_snapshot {\n-\tmy (@fmts) = @_;\n+\tmy ($key, @fmts) = @_;\n \n-\tmy ($val) = git_get_project_config('snapshot');\n+\tmy ($val) = git_get_project_config($key);\n \n \tif ($val) {\n \t\t@fmts = ($val eq 'none' ? () : split /\\s*[,\\s]\\s*/, $val);\n-- \n1.5.6.5\n"},{"id":"98056","messageId":"7vmyewqypk.fsf@gitster.siamese.dyndns.org","threadId":"16736","inReplyTo":"1229408179-7655-1-git-send-email-kraai@ftbfs.org","subject":"Re: [PATCH] gitweb: unify boolean feature subroutines","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-12-16T09:03:03Z","receivedAt":"2008-12-16T09:03:03Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"I'll queue this in 'pu' for now; it has obvious and trivial conflicts with\nother gitweb series that introduce new features ;-)\n\nAnd regarding your follow-up patch you called \"churn\", I think it is\nprobably a good idea in the longer term, although I haven't really\nlooked at all the callers to make sure everybody would be happy.\n\nBut a change to the function signature of feature subroutines is not\nsomething I'd like to apply while other series that want to add new\nfeatures are still cooking.  How about doing these two patches as the\nfirst thing that goes to 'next' after 1.6.1, and then force other series\nrebase on top of your change?  Alternatively, we could make you wait until\nother series do settle in 'next' and then apply your change rebased on\nthem, but I think that is probably less optimal.\n\nThanks.\n"},{"id":"98075","messageId":"20081216142357.GF4529@ftbfs.org","threadId":"16736","inReplyTo":"7vmyewqypk.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] gitweb: unify boolean feature subroutines","fromName":"Matt Kraai","fromEmail":"kraai@ftbfs.org","sentAt":"2008-12-16T14:23:57Z","receivedAt":"2008-12-16T14:23:57Z","isPatch":true,"sender":{"key":"kraai@ftbfs.org","avatar":null},"body":"On Tue, Dec 16, 2008 at 01:03:03AM -0800, Junio C Hamano wrote:\n> But a change to the function signature of feature subroutines is not\n> something I'd like to apply while other series that want to add new\n> features are still cooking.  How about doing these two patches as the\n> first thing that goes to 'next' after 1.6.1, and then force other series\n> rebase on top of your change?  Alternatively, we could make you wait until\n> other series do settle in 'next' and then apply your change rebased on\n> them, but I think that is probably less optimal.\n\nOK, I'll resubmit the patches on top of 'next' once 1.6.1 is\nreleased.  Thanks for your help,\n\n-- \nMatt                                                 http://ftbfs.org/\n"},{"id":"98104","messageId":"20081217081028.GA3640@machine.or.cz","threadId":"16736","inReplyTo":"20081216142357.GF4529@ftbfs.org","subject":"Re: [PATCH] gitweb: unify boolean feature subroutines","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2008-12-17T08:10:28Z","receivedAt":"2008-12-17T08:10:28Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Hi,\n\nOn Tue, Dec 16, 2008 at 06:23:57AM -0800, Matt Kraai wrote:\n> On Tue, Dec 16, 2008 at 01:03:03AM -0800, Junio C Hamano wrote:\n> > But a change to the function signature of feature subroutines is not\n> > something I'd like to apply while other series that want to add new\n> > features are still cooking.  How about doing these two patches as the\n> > first thing that goes to 'next' after 1.6.1, and then force other series\n> > rebase on top of your change?  Alternatively, we could make you wait until\n> > other series do settle in 'next' and then apply your change rebased on\n> > them, but I think that is probably less optimal.\n> \n> OK, I'll resubmit the patches on top of 'next' once 1.6.1 is\n> released.  Thanks for your help,\n\nis it worth keeping them separate? Just a single patch makes more sense\nto me, the interface is much nicer in the latter than in the former. :-)\n\n\t\t\t\tPetr \"Pasky\" Baudis\n"},{"id":"98107","messageId":"7vabavp60k.fsf@gitster.siamese.dyndns.org","threadId":"16736","inReplyTo":"20081217081028.GA3640@machine.or.cz","subject":"Re: [PATCH] gitweb: unify boolean feature subroutines","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-12-17T08:20:27Z","receivedAt":"2008-12-17T08:20:27Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis <pasky@suse.cz> writes:\n\n> Hi,\n>\n> On Tue, Dec 16, 2008 at 06:23:57AM -0800, Matt Kraai wrote:\n>> On Tue, Dec 16, 2008 at 01:03:03AM -0800, Junio C Hamano wrote:\n>> > But a change to the function signature of feature subroutines is not\n>> > something I'd like to apply while other series that want to add new\n>> > features are still cooking.  How about doing these two patches as the\n>> > first thing that goes to 'next' after 1.6.1, and then force other series\n>> > rebase on top of your change?  Alternatively, we could make you wait until\n>> > other series do settle in 'next' and then apply your change rebased on\n>> > them, but I think that is probably less optimal.\n>> \n>> OK, I'll resubmit the patches on top of 'next' once 1.6.1 is\n>> released.  Thanks for your help,\n>\n> is it worth keeping them separate? Just a single patch makes more sense\n> to me, the interface is much nicer in the latter than in the former. :-)\n\nI agree.\n\nIt should come *first* before other topics that are not in 'master/next'\nand change the function signature of feature subs of only existing (read:\nin 'master') ones.  This will force gb/gitweb-patch (and anybody else's\npatch that haven't been submitted, waiting during the -rc period) to be\nrebased on top of the updated interface, but that's life.\n"}]}