From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Pierre Habouzit <madcoder@debian.org>
Cc: git@vger.kernel.org, torvalds@linux-foundation.org,
gitster@pobox.com, peff@peff.net
Subject: Re: [PATCH 1/6] revisions: refactor init_revisions and setup_revisions.
Date: Tue, 8 Jul 2008 13:43:15 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.1.00.0807081339270.4319@eeepc-johanness> (raw)
In-Reply-To: <20080708110624.GF19202@artemis.madism.org>
Hi,
On Tue, 8 Jul 2008, Pierre Habouzit wrote:
> On Tue, Jul 08, 2008 at 10:59:43AM +0000, Johannes Schindelin wrote:
>
> > On Tue, 8 Jul 2008, Pierre Habouzit wrote:
> >
> > > setup_revisions has been split in two: parse_revisions that does
> > > (almost) only argument parsing, to be more like what parse-options
> > > can do, and setup_revisions that does the rest.
> >
> > I do not see the sense of this change, except
>
> Well, it's required to remove "parse_revisions" at once if we one day
> reach the goal of having only parse-opt based parsers.
We can do that, then.
We do not need to do that, now.
In the meantime, your patch series of already pretty large patches gets
even larger, which prevents me from being able to review them.
Sad,
Dscho
P.S.: Please do not pull things at me like "it is so convenient to be able
to drop "0, NULL, " for many sites". That is not even funny. This case
does not need more convenience. The other cases do.
next prev parent reply other threads:[~2008-07-08 11:44 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-08 9:55 Migration of builtin-blame to parse-option Pierre Habouzit
2008-07-08 9:55 ` [PATCH 1/6] revisions: refactor init_revisions and setup_revisions Pierre Habouzit
2008-07-08 9:56 ` [PATCH 2/6] revisions: split the pure option parsing out from parse_revisions Pierre Habouzit
2008-07-08 9:56 ` [PATCH 3/6] revisions: parse_revisions refactor Pierre Habouzit
2008-07-08 9:56 ` [PATCH 4/6] revisions: split handle_revision_args from parse_revisions Pierre Habouzit
2008-07-08 9:56 ` [PATCH 5/6] git-blame: migrate to incremental parse-option [1/2] Pierre Habouzit
2008-07-08 9:56 ` [PATCH 6/6] git-blame: migrate to incremental parse-option [2/2] Pierre Habouzit
2008-07-08 10:51 ` [PATCH 2/6] revisions: split the pure option parsing out from parse_revisions Johannes Sixt
2008-07-08 11:00 ` Pierre Habouzit
2008-07-08 11:25 ` Pierre Habouzit
2008-07-08 10:59 ` [PATCH 1/6] revisions: refactor init_revisions and setup_revisions Johannes Schindelin
2008-07-08 11:06 ` Pierre Habouzit
2008-07-08 11:43 ` Johannes Schindelin [this message]
2008-07-08 12:48 ` Pierre Habouzit
2008-07-08 10:02 ` Migration of builtin-blame to parse-option Pierre Habouzit
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=alpine.DEB.1.00.0807081339270.4319@eeepc-johanness \
--to=johannes.schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=madcoder@debian.org \
--cc=peff@peff.net \
--cc=torvalds@linux-foundation.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox