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