From: Junio C Hamano <gitster@pobox.com>
To: Petr Baudis <pasky@suse.cz>
Cc: Matt Kraai <kraai@ftbfs.org>,
git@vger.kernel.org, Jakub Narebski <jnareb@gmail.com>
Subject: Re: [PATCH] gitweb: unify boolean feature subroutines
Date: Wed, 17 Dec 2008 00:20:27 -0800 [thread overview]
Message-ID: <7vabavp60k.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <20081217081028.GA3640@machine.or.cz> (Petr Baudis's message of "Wed, 17 Dec 2008 09:10:28 +0100")
Petr Baudis <pasky@suse.cz> writes:
> Hi,
>
> On Tue, Dec 16, 2008 at 06:23:57AM -0800, Matt Kraai wrote:
>> On Tue, Dec 16, 2008 at 01:03:03AM -0800, Junio C Hamano wrote:
>> > But a change to the function signature of feature subroutines is not
>> > something I'd like to apply while other series that want to add new
>> > features are still cooking. How about doing these two patches as the
>> > first thing that goes to 'next' after 1.6.1, and then force other series
>> > rebase on top of your change? Alternatively, we could make you wait until
>> > other series do settle in 'next' and then apply your change rebased on
>> > them, but I think that is probably less optimal.
>>
>> OK, I'll resubmit the patches on top of 'next' once 1.6.1 is
>> released. Thanks for your help,
>
> is it worth keeping them separate? Just a single patch makes more sense
> to me, the interface is much nicer in the latter than in the former. :-)
I agree.
It should come *first* before other topics that are not in 'master/next'
and change the function signature of feature subs of only existing (read:
in 'master') ones. This will force gb/gitweb-patch (and anybody else's
patch that haven't been submitted, waiting during the -rc period) to be
rebased on top of the updated interface, but that's life.
prev parent reply other threads:[~2008-12-17 8:22 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-15 14:51 [PATCH] gitweb: make feature_blame return a list Matt Kraai
2008-12-15 14:51 ` [PATCH] gitweb: unify boolean feature subroutines Matt Kraai
2008-12-15 22:21 ` Junio C Hamano
2008-12-15 22:20 ` [PATCH] gitweb: make feature_blame return a list Junio C Hamano
2008-12-15 22:52 ` Giuseppe Bilotta
2008-12-16 2:46 ` Matt Kraai
2008-12-16 5:38 ` Junio C Hamano
2008-12-16 6:16 ` [PATCH] gitweb: unify boolean feature subroutines Matt Kraai
2008-12-16 7:36 ` [PATCH] gitweb: pass the option name to the feature callback Matt Kraai
2008-12-16 9:03 ` [PATCH] gitweb: unify boolean feature subroutines Junio C Hamano
2008-12-16 14:23 ` Matt Kraai
2008-12-17 8:10 ` Petr Baudis
2008-12-17 8:20 ` Junio C Hamano [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vabavp60k.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=jnareb@gmail.com \
--cc=kraai@ftbfs.org \
--cc=pasky@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.