From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: "Kristian Høgsberg" <krh@redhat.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 9/9] Implement git commit as a builtin command.
Date: Tue, 18 Sep 2007 00:16:20 +0100 (BST) [thread overview]
Message-ID: <Pine.LNX.4.64.0709180012420.28586@racer.site> (raw)
In-Reply-To: <1190069881.10112.10.camel@hinata.boston.redhat.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1800 bytes --]
Hi,
On Mon, 17 Sep 2007, Kristian H?gsberg wrote:
> On Thu, 2007-09-06 at 17:59 +0100, Johannes Schindelin wrote:
> >
> > On Wed, 5 Sep 2007, Kristian Høgsberg wrote:
> >
> > > - builtin-runstatus.o \
> >
> > Better keep it; some people's scripts could depend on it.
>
> Seriously? Why don't we remove it and see if somebody yells? It's more
> of an implementation detail than most other git commands; if you need
> status output in your script why wouldn't you just run git status?
git status is deemed porcelain.
Yes, we recently converted a few things to use "git log", which is
porcelain, too, and I was not happy...
But then, you're right, we could just go and break peoples' scripts, if
they indeed did not use "git diff" directly.
> > > +struct option {
> > > + enum option_type type;
> > > + const char *long_name;
> > > + char short_name;
> > > + void *value;
> > > +};
> > > +
> > > +static int scan_options(const char ***argv, struct option *options)
> > > +{
> >
> > I would not (no longer, anyway) be opposed to replacing the option parsing
> > in git with getopt(); I hear that it is small enough to keep a copy in
> > compat/getopt.c.
> >
> > But let's go forward with builtin-commit; getopt() can come later.
>
> I don't know. I think it's a situation much like the string library
> discussion. It's a small enough dependency (70 lines!) that there's no
> gain in depending on an external implementation, and we can tailor it to
> gits needs as we extend the use within git. And we can call it gitopt!
Hm. I liked the semantics of getopt better, but what the heck.
> I'm sending an updated version against Pierre's strbuf changes now. It's
> a smaller patch set, so hopefully we can get it in soon.
Yes, that would be good.
Thanks,
Dscho
next prev parent reply other threads:[~2007-09-17 23:17 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-06 0:23 [PATCH 1/9] Enable wt-status output to a given FILE pointer Kristian Høgsberg
2007-09-06 0:23 ` [PATCH 2/9] Enable wt-status to run against non-standard index file Kristian Høgsberg
2007-09-06 0:23 ` [PATCH 3/9] Add strbuf_printf() to do formatted printing to a strbuf Kristian Høgsberg
2007-09-06 0:23 ` [PATCH 4/9] Introduce entry point for launching add--interactive Kristian Høgsberg
2007-09-06 0:23 ` [PATCH 5/9] Introduce strbuf_read_fd() Kristian Høgsberg
2007-09-06 0:23 ` [PATCH 6/9] Rewrite launch_editor, create_tag and stripspace to use strbufs Kristian Høgsberg
2007-09-06 0:23 ` [PATCH 7/9] Add strbuf_read_path() Kristian Høgsberg
2007-09-06 0:23 ` [PATCH 8/9] Export rerere() and launch_editor() Kristian Høgsberg
2007-09-06 0:23 ` [PATCH 9/9] Implement git commit as a builtin command Kristian Høgsberg
2007-09-06 16:59 ` Johannes Schindelin
2007-09-17 22:58 ` Kristian Høgsberg
2007-09-17 23:16 ` Johannes Schindelin [this message]
2007-09-17 23:56 ` Jeff King
2007-09-18 0:11 ` Kristian Høgsberg
2007-09-06 16:40 ` [PATCH 7/9] Add strbuf_read_path() Johannes Schindelin
2007-09-06 16:38 ` [PATCH 6/9] Rewrite launch_editor, create_tag and stripspace to use strbufs Johannes Schindelin
2007-09-17 22:59 ` Kristian Høgsberg
2007-09-06 16:31 ` [PATCH 4/9] Introduce entry point for launching add--interactive Johannes Schindelin
2007-09-17 23:13 ` Kristian Høgsberg
2007-09-17 23:27 ` Johannes Schindelin
2007-09-06 8:55 ` [PATCH 3/9] Add strbuf_printf() to do formatted printing to a strbuf Junio C Hamano
2007-09-06 9:43 ` Pierre Habouzit
2007-09-06 9:50 ` Pierre Habouzit
2007-09-06 16:27 ` [PATCH 1/9] Enable wt-status output to a given FILE pointer Johannes Schindelin
2007-09-17 23:30 ` Kristian Høgsberg
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.64.0709180012420.28586@racer.site \
--to=johannes.schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=krh@redhat.com \
/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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).