Thread (22 messages) flat view 22 messages, 3 authors, 2016-06-15

Re: [PATCH 9/9] Implement git commit as a builtin command.

From: Johannes Schindelin <hidden>
Date: 2016-06-15 22:43:35

Hi,

On Mon, 17 Sep 2007, Kristian H?gsberg wrote:
On Thu, 2007-09-06 at 17:59 +0100, Johannes Schindelin wrote:
quoted
On Wed, 5 Sep 2007, Kristian Høgsberg wrote:
quoted
-	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.
quoted
quoted
+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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help