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
